Re: plpgsql GUC variable: custom or built-in?

On Mon, Apr 19, 2010 at 10:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Apr 19, 2010 at 9:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> The problem is that making a "custom" variable SUSET doesn't really
>>> work: the system will not accept a value that's assigned before the
>>> loadable module is loaded, even if it was assigned by a superuser.
>>> I suggested a fix in the referenced thread, but it's not exactly an
>>> ideal fix.
>
>> Well, at this point the issue is deciding whether we're going to try
>> to do anything about this before beta.
>
> The reason it seems of concern for 9.0 is that now we have a custom
> SUSET variable in plpgsql.  If we don't fix this then we need to think
> hard about the alternative of forcing the variable into the core code
> to avoid the gotchas.

Well, having reread your proposed solution, it sounds pretty
reasonable to me. You're never going to be able to make totally
sensible decisions about GUCs if the code that defines those GUCs
isn't loaded, so requiring that the code be loaded before any GUCs are
set seems like a sensible thing to do. On the other hand, if forcing
this into core gets a beta out the door sooner, maybe that's the way
to go, even though I wouldn't exactly classify it as an elegant
solution.

Or to put it another way - this thread has been sitting idle for 5
months; it's time to make a decision.

...Robert