Re: Proposal for Allow postgresql.conf values to be changed via SQL
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Amit kapila <amit.kapila@huawei.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, "cedric@2ndquadrant.com" <cedric@2ndquadrant.com>, Greg Smith <greg@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>, Magnus Hagander <magnus@hagander.net>, Christopher Browne <cbbrowne@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>
Date: 2012-11-30T19:39:17Z
Lists: pgsql-hackers
On Wed, Nov 28, 2012 at 9:47 AM, Amit kapila <amit.kapila@huawei.com> wrote: > 5. PERSISTENT Keyword is added to the reserved keyword list. As it was giving some errors given below while parsing gram.y > 15 shift/reduce conflicts . Allow me to be the first to say that any syntax for this feature that involves reserving new keywords is a bad syntax. The cost of an unreserved keyword is that the parser gets a little bigger and slows down, but previous experimentation shows that the effect is pretty small. However, adding a new reserved keyword breaks user applications. It is hardly difficult to imagine that there are a decent number of users who have columns or PL/pgsql variables called "persistent". Let's not break them. Instead, since there were multiple proposed syntaxes for this feature, let's just pick one of the other ones that doesn't have this problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company