From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | depesz(at)depesz(dot)com, pgsql-general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: How to I select value of GUC that has - in its name? |
Date: | 2021-02-09 17:00:42 |
Message-ID: | 866534.1612890042@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:
> On 2/9/21 7:45 AM, hubert depesz lubaczewski wrote:
>> but I find it curious that I can set the guc using normal-ish SET, but
>> can't get it using SHOW or even select current_setting()
> Yeah, I think that part is a bug report.
After digging around in the code, I find the reason is that the entries in
pg_db_role_setting.setconfig are parsed with ParseLongOption, which quoth:
/*
* A little "long argument" simulation, although not quite GNU
* compliant. Takes a string of the form "some-option=some value" and
* returns name = "some_option" and value = "some value" in malloc'ed
* storage. Note that '-' is converted to '_' in the option name. If
* there is no '=' in the input string then value will be NULL.
*/
Sure enough,
regression=> show custom."bad-guc";
ERROR: unrecognized configuration parameter "custom.bad-guc"
regression=> show custom."bad_guc";
custom.bad_guc
----------------
1a
(1 row)
So that's where the setting went.
There's a second problem here with arbitrary GUC names, which is that
a name containing '=' isn't exactly gonna do what you want either.
There are probably other places that are not terribly careful about
funny characters in GUC names. In a quick test, I see that pg_dumpall
seems to dump the ALTER USER SET safely, but I wouldn't want to bet
that everything else copes.
I think we should probably sanitize custom GUC names at least to the
extent of forbidding '=' and '-'. Maybe we should go further and
insist they look like regular identifiers.
(Fortunately, ALTER USER SET with a custom GUC is superuser-only,
so there's no need to worry about security issues here. But we
should eliminate surprises.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Zagrabelny | 2021-02-09 17:06:32 | quoted-printable to jsonb |
Previous Message | luis.roberto | 2021-02-09 16:23:06 | Re: How does Postgres decide if to use additional workers? |