Re: custom variables and PGC_SUSET issue
От | Robert Haas |
---|---|
Тема | Re: custom variables and PGC_SUSET issue |
Дата | |
Msg-id | CA+Tgmobwnvah9sJ-=0Yt7c4QQsq3VhXfO2Q7OvsqRu8aCbwbGA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: custom variables and PGC_SUSET issue (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: custom variables and PGC_SUSET issue
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: