Michael Meskes <meskes@postgresql.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
