Re: plpgsql GUC variable: custom or built-in? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: plpgsql GUC variable: custom or built-in?
Date
Msg-id 15736.1271883758@sss.pgh.pa.us
Whole thread Raw
In response to Re: plpgsql GUC variable: custom or built-in?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> Well, if there are no other comments, I'll push forward with the fix
> proposed here:
> http://archives.postgresql.org/pgsql-hackers/2009-11/msg00531.php

Done.  I did not make the change I speculated about of allowing
completely unknown variables (those that don't even match
custom_variable_classes) to be set by superusers.  It would be a very
minor tweak to the committed code to allow that, but I'm not convinced
that making a corner case in dump/restore slightly easier is worth the
loss of error checking.  In practice, if you have ALTER ... SETs for
custom variables, you'd better list their modules in
custom_variable_classes, or it won't work nicely.  I see no really
strong reason not to fix that parameter before you restore instead of
after.
        regards, tom lane


pgsql-hackers by date:

Previous
From: feng tian
Date:
Subject: libpq connectoin redirect
Next
From: John R Pierce
Date:
Subject: Re: libpq connectoin redirect