Re: Proposal for Allow postgresql.conf values to be changed via SQL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Proposal for Allow postgresql.conf values to be changed via SQL
Дата
Msg-id 12948.1354548511@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Proposal for Allow postgresql.conf values to be changed via SQL
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Dec 1, 2012 at 11:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> But even if we can't make that work, it's not grounds for reserving
>>> PERSISTENT.  Instead I'd be inclined to forget about "RESET PERSISTENT"
>>> syntax and use, say, SET PERSISTENT var_name TO DEFAULT to mean that.
>>> (BTW, I wonder what behavior that syntax has now in your patch.)
>> 
>> In fact, rereading this, I wonder why you think "RESET PERSISTENT"
>> is a good idea even if there were no bison issues with it.  We don't
>> write RESET LOCAL or RESET SESSION, so it seems asymmetric to have
>> RESET PERSISTENT.

> I think this feature is more analagous to ALTER DATABASE .. SET or
> ALTER ROLE .. SET.  Which is, incidentally, another reason I don't
> like SET PERSISTENT as a proposed syntax.  But even if we stick with
> that syntax, it feels weird to have an SQL command to put a line into
> postgresql.conf.auto and no syntax to take it back out again.

Neither of you have responded to the point about what "SET PERSISTENT
var_name TO DEFAULT" will do, and whether it is or should be different
from RESET PERSISTENT, and if not why we should put the latter into
the grammar as well.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Review: Extra Daemons / bgworker
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Proposal for Allow postgresql.conf values to be changed via SQL