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 | 13044.1354548751@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 Mon, Dec 3, 2012 at 6:38 AM, Amit Kapila <amit.kapila@huawei.com> wrote: >> opt_persistent: PERSISTENT { $$ = TRUE; } >> | /*EMPTY*/ %prec Op { $$ = FALSE; } >> ; >> >> I am not sure if there are any problems with above change. > We usually try to avoid operator precedence declarations. They > sometimes have unforeseen consequences. Yes. This is not an improvement over factoring out opt_persistent as I recommended previously. >> Found one difference with the change is, the command "reset persistent" >> execution results in different errors with/without change. >> >> without change: >> unrecognized configuration parameter "persistent". >> with change: >> syntax error at or near ";" > ...but this in itself doesn't seem like a problem. Indeed, this demonstrates why kluging the behavior this way isn't a good solution. If PERSISTENT is an unreserved word, then you *should* get the former error, because it's a perfectly valid interpretation of the command. If you get the latter then PERSISTENT is not acting like an unreserved word. regards, tom lane
В списке pgsql-hackers по дате отправления: