On Wed, Sep 7, 2011 at 2:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Yeah, I guess we don't have many good short-term options. I continue
to think that this whole facility is mis-designed, though.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company