Allow custom parameters with more than one dot in config files.

Started by Alexander Kukushkinabout 2 years ago3 messages
#1Alexander Kukushkin
cyberdemn@gmail.com
1 attachment(s)

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

Attachments:

v1-0001-multidot-custom-params.patchtext/x-patch; charset=US-ASCII; name=v1-0001-multidot-custom-params.patchDownload
From 755b7d9a44901f3dc5f86f83c39c98c269a98c85 Mon Sep 17 00:00:00 2001
From: Alexander Kukushkin <cyberdemn@gmail.com>
Date: Tue, 19 Dec 2023 13:21:43 +0100
Subject: [PATCH] Allow custom parameters with more than one dot in config
 files.

To make it consistent with the rest of the code responsible for GUC
handling.
---
 src/backend/utils/misc/guc-file.l | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/backend/utils/misc/guc-file.l b/src/backend/utils/misc/guc-file.l
index 41d62a9f23..22250d12a1 100644
--- a/src/backend/utils/misc/guc-file.l
+++ b/src/backend/utils/misc/guc-file.l
@@ -82,7 +82,8 @@ LETTER			[A-Za-z_\200-\377]
 LETTER_OR_DIGIT [A-Za-z_0-9\200-\377]
 
 ID				{LETTER}{LETTER_OR_DIGIT}*
-QUALIFIED_ID	{ID}"."{ID}
+SUB_ID          "."{ID}
+QUALIFIED_ID	{ID}{SUB_ID}+
 
 UNQUOTED_STRING {LETTER}({LETTER_OR_DIGIT}|[-._:/])*
 STRING			\'([^'\\\n]|\\.|\'\')*\'
-- 
2.34.1

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alexander Kukushkin (#1)
Re: Allow custom parameters with more than one dot in config files.

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

#3Alexander Kukushkin
cyberdemn@gmail.com
In reply to: Tom Lane (#2)
Re: Allow custom parameters with more than one dot in config files.

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