On Saturday, December 01, 2012 1:30 AM Tom Lane wrote:
> 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.
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
all.
If you have any idea or any hint where similar syntax is used, please point
me I will refer it.
Any other Suggestions?
With Regards,
Amit Kapila.