From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: yacc guru needed |
Date: | 2000-10-04 15:49:30 |
Message-ID: | 3420.970674570@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Meskes <meskes(at)postgresql(dot)org> writes:
> Anyway, the problem is that some rules expand to either Iconst, FCONST or
> Sconst. So do I have to change all these rules?
> Just changing the rule for Iconst and Sconst e.g doesn't work since
> AexprConst expands to the variable in two different ways. And bison
> certainly does not like that.
It looks to me like you ought to try to clean up the not-very-consistent
treatment of constants in the grammar. Some rules use raw ICONST, some
use Iconst, some use IntegerOnly --- ugh. There's no need for all that
variation IMHO.
I'd think about making a small number of productions like
AnyConst: ICONST | FCONST | SCONST
IntegerConst: ICONST | - ICONST
StringConst: SCONST
and trying to make *all* the grammar's uses of constants go through one
of these productions. For instance AexprConst would produce either
AnyConst or one of the cast-decorated variants. Then, ecpg's grammar
would differ from the backend's grammar by adding ":variable" as an
alternative to each of this small group of productions.
The trick is to choose a good set of gateway productions; the above is
probably not quite right...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-10-04 15:57:20 | Re: WaitOnLock |
Previous Message | Fabrice Scemama | 2000-10-04 15:48:03 | Re: I want tips for debugging deadlocks |