> 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