Allow custom parameters with more than one dot in config files.
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:t48916psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 04:50 AM.
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 t48916_1 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 t48916_1 && git checkout t48916_1Patchset v1 (message #1) is on t48916_1
Hi hacker,
At the moment the only requirement for custom parameter names is that they
should have one or more dots.
For example:
test5=# set a.b.c.d = 1;
SET
test5=# show a.b.c.d;
a.b.c.d
---------
1
(1 row)
But, Postgres fails to start if such parameters are set in the
configuration file with the following error:
LOG: syntax error in file "/tmp/cluster/postgresql.auto.conf" line 8, near
token "a.b.c.d"
FATAL: configuration file "postgresql.auto.conf" contains errors
What is more fun, ALTER SYSTEM allows writing such parameters to the
postgresql.auto.conf file if they are defined in a session:
test5=# show a.b.c.d;
ERROR: unrecognized configuration parameter "a.b.c.d"
test5=# alter system set a.b.c.d = 1;
ERROR: unrecognized configuration parameter "a.b.c.d"
test5=# set a.b.c.d = 1;
SET
test5=# alter system set a.b.c.d = 1;
ALTER SYSTEM
In my opinion it would be fair to make parsing of config files with the
rest of the code responsible for GUC handling by allowing custom parameters
containing more than one dot.
The fix is rather simple, please find the patch attached.
Regards,
--
Alexander Kukushkin
Alexander Kukushkin <cyberdemn@gmail.com> writes:
At the moment the only requirement for custom parameter names is that they
should have one or more dots.
...
But, Postgres fails to start if such parameters are set in the
configuration file with the following error:
Hmm.
In my opinion it would be fair to make parsing of config files with the
rest of the code responsible for GUC handling by allowing custom parameters
containing more than one dot.
I wonder if we wouldn't be better advised to require exactly one dot.
This isn't a feature that we really encourage users to use, and the
further we move the goalposts for it, the harder it will be to replace
it. In particular I doubt the long-stalled session-variables patch
could support such names, since it needs the names to conform to
normal SQL rules.
regards, tom lane
On Tue, 19 Dec 2023 at 16:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wonder if we wouldn't be better advised to require exactly one dot.
This isn't a feature that we really encourage users to use, and the
further we move the goalposts for it, the harder it will be to replace
it. In particular I doubt the long-stalled session-variables patch
could support such names, since it needs the names to conform to
normal SQL rules.
If I understand correctly, session variables don't even intersect with
custom parameters.
Also, they seems to work fine with FQDN:
postgres=# create database testdb;
CREATE DATABASE
postgres=# \c testdb
You are now connected to database "testdb" as user "akukushkin".
testdb=# create schema testschema;
CREATE SCHEMA
testdb=# create variable testdb.testschema.testvar int;
CREATE VARIABLE
testdb=# let testdb.testschema.testvar = 1;
LET
testdb=# select testdb.testschema.testvar;
testvar
---------
1
(1 row)
Regards,
--
Alexander Kukushkin