> 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


Reply via email to