Re: custom variables and PGC_SUSET issue

On Wed, Sep 7, 2011 at 2:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Sep 7, 2011 at 2:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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