Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Sep 7, 2011 at 2:05 PM, Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
