On Saturday, December 01, 2012 1:30 AM Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Wed, Nov 28, 2012 at 9:47 AM, Amit kapila <amit.kap...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
