Re: [HACKERS] shift/reduce problem with ecpg
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] shift/reduce problem with ecpg |
Дата | |
Msg-id | 353C31CF.DC75AB81@alumni.caltech.edu обсуждение исходный текст |
Ответ на | shift/reduce problem with ecpg (Michael Meskes <meskes@topsystem.de>) |
Ответы |
Re: [HACKERS] shift/reduce problem with ecpg
|
Список | pgsql-hackers |
> gram.y says: > > opt_indirection: ... > | '[' a_expr ']' opt_indirection > | '[' a_expr ':' a_expr ']' opt_indirection > ... > > IMO a_expr is exactly where I have to enter C variable support. > As you might expect this results in a shift/reduce > conflict since there is no way to decide whether the second name is > the indicator variable or a coloumn name. > > Any idea how to solve this? Yes. If you really want to allow zero, one, or two colons, and only that number, then you can explicitly define those cases and separate them out from the a_expr syntax except as an argument. Look in gram.y for "b_expr" which accomplishes a similar thing for the BETWEEN operator. For that case, the AND usage was ambiguous since it can be used for boolean expressions and is also used with the BETWEEN operator. Your biggest problem is probably the case with one colon, since it could be either an indicator variable or the second value in a range. You might want to require three or four colons when using indicator variables in this context. Or, as I did with the "b_expr" and "AND" boolean expressions, you can require parens around the variable/indicator pair. e.g. xxx [ name : name ] -- this is a range xxx [ (name : name) ] -- this is an indicator variable - Tom
В списке pgsql-hackers по дате отправления: