Re: How to I select value of GUC that has - in its name?
От | Adrian Klaver |
---|---|
Тема | Re: How to I select value of GUC that has - in its name? |
Дата | |
Msg-id | 18e0b278-14af-4fac-8f1a-866f58b0d150@aklaver.com обсуждение исходный текст |
Ответ на | Re: How to I select value of GUC that has - in its name? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On 2/9/21 9:00 AM, Tom Lane wrote: > Adrian Klaver <adrian.klaver@aklaver.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.) Hmm, further food for thought: test(5432)=# alter user aklaver reset custom."bad_guc" ; ALTER ROLE test(5432)=# select setconfig from pg_db_role_setting where setrole = 'aklaver'::regrole; setconfig --------------------- {custom.bad-guc=1a} (1 row) test(5432)=# alter user aklaver reset custom."bad-guc" ; ALTER ROLE test(5432)=# select setconfig from pg_db_role_setting where setrole = 'aklaver'::regrole; setconfig ----------- (0 rows) > > regards, tom lane > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: