I was confused when I though so I found a solution of 1 shift/reduce conflict :(

All identificators used for buildin functions have to be a
col_name_keywords or reserved keyword. There is conflict with our
(probably obsolete) feature SELECT colname(tabname). So for this
moment the real solution is removing CUBE and ROLLUP from keywords and
dynamically testing a funcname in transformation stage - what is
slower and more ugly.



Pavel Stehule

2010/8/7 Pavel Stehule <pavel.steh...@gmail.com>:
> 2010/8/7 Joshua Tolley <eggyk...@gmail.com>:
>> On Thu, Aug 05, 2010 at 04:46:51PM +0200, Pavel Stehule wrote:
>>> I am sending a updated version.
>> I've been looking at the changes to gram.y, and noted the comment under 
>> func_expr
>> where you added CUBE and ROLLUP definitions. It says that CUBE can't be a
>> reserved keyword because it's already used in the cube contrib module. But
>> then the changes to kwlist.h include this:
> I am little bit confused now - it's bad comment - and I have to verify
> it. What I remember, we cannot to use a two parser's rules, because it
> going to a conflict. So there have to be used a trick with a moving to
> decision to transform stage, where we have a context info. I have to
> recheck a minimal level - probably it can't be a RESERVED_KEYWORD.
> Because then we can't to create a function "cube".
>> ...
>> ...and CUBE and ROLLUP are added in gram.y under the reserved_keyword list. I
>> realize things like CURRENT_TIME, that also have special entries in the
>> func_expr grammar, are also reserved keywords, but this all seems at odds 
>> with
>> the comment. What am I missing? Is the comment simply pointing out that the
>> designation of CUBE and ROLLUP as reserved keywords will have to change at
>> some point, but it hasn't been implemented yet (or no one has figured out how
>> to do it)?
>> --
>> Joshua Tolley / eggyknap
>> End Point Corporation
>> http://www.endpoint.com
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> xq0AoID75rCPiW8yf29OSkaJVza1FQt5
>> =PcLs
>> -----END PGP SIGNATURE-----

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to