yacc guru needed
I would like to allow variables in ECPG at all positions the backend allows
constants. But I wonder how to get this done in the parser.
1) I need to allow :variable:indicator in AexprConst since this is the only
position where NULL is a possible constant.
2) :variable should be allowed whereever Iconst, FCONST and Sconst are used.
This would finally allow us to use something like "exec sql move :number ...".
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.
But just adding a combined Const rule won't do either, since there are also
rules just asking for a special constant like in the aformentioned MOVE
command.
Finally bison cannot distinguish between character and numerical variables.
I can implement such a check but is it a good idea? How about I want to
store my numerical passwords in an int since it's calculated? etc.
Any ideas anyone?
Michael
--
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
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
On Wed, Oct 04, 2000 at 11:49:30AM -0400, Tom Lane wrote:
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 agree.
I'd think about making a small number of productions like
...
Yes, I thought about this too.
If noone else is working on it I will as soon as I find time.
Michael
--
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!