Re: Proposal for Allow postgresql.conf values to be changed via SQL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date
Msg-id 22694.1354305573@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Amit Kapila <amit.kapila@huawei.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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.

Let me put that a little more strongly: syntax that requires reserving
words that aren't reserved in the SQL standard is unacceptable.

Even if the new word is reserved according to SQL, we'll frequently
try pretty hard to avoid making it reserved in Postgres, so as not to
break existing applications.  But if it's not in the standard then
you're breaking applications that can reasonably expect not to get
broken.

But having said that, it's not apparent to me why inventing SET
PERSISTENT should require reserving PERSISTENT.  In the existing
syntaxes SET LOCAL and SET SESSION, there's not been a need to
reserve LOCAL or SESSION.  Maybe you're just trying to be a bit
too cute in the grammar productions?  Frequently there's more than
one way to do it and not all require the same level of keyword
reservedness.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: initdb.c::main() too large
Next
From: Robert Haas
Date:
Subject: Re: Enabling frontend-only xlog "desc" routines