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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit kapila <amit(dot)kapila(at)huawei(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, "cedric(at)2ndquadrant(dot)com" <cedric(at)2ndquadrant(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date: 2012-11-30 19:59:33
Message-ID: 22694.1354305573@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Nov 28, 2012 at 9:47 AM, Amit kapila <amit(dot)kapila(at)huawei(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-11-30 20:03:21 Re: Enabling frontend-only xlog "desc" routines
Previous Message Bruce Momjian 2012-11-30 19:50:40 Re: initdb.c::main() too large