Ensure that maxlen is an integer value in dict_int configuration
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t38445psql -h localhost -U postgresBuilt from patchset v3 (message #3), July 27, 2026 at 08:49 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t38445_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t38445_3 && git checkout t38445_3Patchset v3 (message #3) is on t38445_3
I recently had a usecase for dict_int, typoed my script and spent longer than
I’d like to admit finding said typo. The attached patch scratches my itch by
ensuring that the maxlen parameter to dict_int is integer, instead of silently
setting it to zero on malformed input. Instead of this:
dg=# alter text search dictionary intdict (maxlen = a, rejectlong = true);
ALTER TEXT SEARCH DICTIONARY
dg=# select ts_lexize('intdict', '12345678');
ts_lexize
-----------
{}
(1 row)
.. the attached will error out with “ERROR: maxlen is out of range, must
be integer”, and be more in line with how we handle DefElem values. A quick
grep around the tree didn’t turn up any other defelems doing this so I think
this is the only callsite.
cheers ./daniel
Attachments:
dict_int_maxlen.patchapplication/octet-stream; name=dict_int_maxlen.patchDownload+1-2
On Tue, Mar 27, 2018 at 01:17:20PM +0200, Daniel Gustafsson wrote:
I recently had a usecase for dict_int, typoed my script and spent longer than
I’d like to admit finding said typo. The attached patch scratches my itch by
ensuring that the maxlen parameter to dict_int is integer, instead of silently
setting it to zero on malformed input. Instead of this:dg=# alter text search dictionary intdict (maxlen = a, rejectlong = true);
ALTER TEXT SEARCH DICTIONARY
dg=# select ts_lexize('intdict', '12345678');
ts_lexize
-----------
{}
(1 row)
But the patch breaks options parsing in another place. After the patch:
=# alter text search dictionary intdict (maxlen = 3, rejectlong = true);
ALTER TEXT SEARCH DICTIONARY
=# select ts_lexize('intdict', '12345678');
ERROR: maxlen requires an integer value
It is because all options are stored as string:
=# select dictinitoption from pg_ts_dict where dictname = 'intdict';
dictinitoption
-----------------------------------
maxlen = '5', rejectlong = 'true'
So the right fix could be as it done in postgres_fdw_validator() for
'fetch_size' option.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
On 27 Mar 2018, at 15:04, Arthur Zakirov <a.zakirov@postgrespro.ru> wrote:
But the patch breaks options parsing in another place. After the patch:
So the right fix could be as it done in postgres_fdw_validator() for
'fetch_size' option.
Doh. I had a strtol() first but found the defGetInt32() version elegantly
small.. but I kept testing the former patch the whole time. Attached is my
first version which now turned into the second. Thanks for looking at the
patch, I’ll go stand in the corner a bit now.
cheers ./daniel