Re: custom variables and PGC_SUSET issue - Mailing list pgsql-hackers

From Tom Lane
Subject Re: custom variables and PGC_SUSET issue
Date
Msg-id 26751.1315419676@sss.pgh.pa.us
Whole thread Raw
In response to Re: custom variables and PGC_SUSET issue  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: custom variables and PGC_SUSET issue
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Sep 7, 2011 at 2:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The ones in auto_explain and pg_stat_statements aren't too problematic
>> because those modules are designed to be preloaded by the postmaster.
>> We've avoided adding such variables in modules that aren't intended
>> to be used that way.

> What about plpgsql.variable_conflict?

That one's not really meant to be changed on the fly either; we have
#variable_conflict instead.

The reason why this is hard, and not just a bug to be fixed, is that
it's not clear what to do.  Part of the issue is that we don't remember
whether the current setting was applied by a superuser or not, but even
if we did remember that, what happens at LOAD time if it wasn't?
Silently replacing the value isn't appealing, and neither are the other
options.  It's better to not have such a variable in the first place.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Large C files
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Don't truncate integer part in to_char for 'FM99.'