On Saturday, December 01, 2012 1:30 AM Tom Lane wrote:
> 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>
> >> 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
> 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
The problem is due to RESET PERSISTENT configuration_variable Syntax.
I think the reason is that configuration_variable name can also be
persistent, so its not able to resolve.
I have tried quite a few ways. I shall try some more and send you result of
If you have any idea or any hint where similar syntax is used, please point
me I will refer it.
Any other Suggestions?
In response to
pgsql-hackers by date
|Next:||From: Albe Laurenz||Date: 2012-12-01 10:42:22|
|Subject: Re: Hot Standby Feedback should default to on in 9.3+|
|Previous:||From: Kohei KaiGai||Date: 2012-12-01 07:57:50|
|Subject: Re: [v9.3] OAT_POST_ALTER object access hooks|