Re: yacc guru needed
От | Tom Lane |
---|---|
Тема | Re: yacc guru needed |
Дата | |
Msg-id | 3420.970674570@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | yacc guru needed (Michael Meskes <meskes@postgresql.org>) |
Ответы |
Re: yacc guru needed
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: