> 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.
Oh, that's interesting. Unfortuantley it can also lead to problems:
alter user depesz set custom.bad_guc='2b';
$ select * from pg_db_role_setting where setrole = 'depesz'::regrole;
setdatabase │ setrole │ setconfig
─────────────┼─────────┼───────────────────────────────────────────────────────────────────────────
0 │ 16384 │ {application_name=xxx,custom.guc=123,custom.bad-guc=1a,custom.bad_guc=2b}
(1 row)
And now I can get:
$ show custom."bad_guc";
custom.bad_guc
────────────────
2b
(1 row)
But the bad-guc is no longer available.
> (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.)
Yeah. Realistically I wouldn't use variable names with - in them, but some people clearly are trying.
Thanks, and best regards,
depesz
