Adrian Klaver <adrian.klaver@xxxxxxxxxxx> 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
