I wrote: > One of the possibilities for fixing it is to add productions that > allow table_ref to expand to NULLS_FIRST, WITH_CASCADED, and the > other two-word pseudo-tokens, and then build the appropriate > relation-with-alias syntax tree out of whole cloth. I find this pretty > ugly though, and I'm not sure that table_ref would be the only place > to fix, so I'm inclined not to do it unless we actually get complaints > from the field.
Actually, that way doesn't work, because for example it would fix select * from with cascaded; but not select * from public.with cascaded; So my suspicion that there'd be too many places to fix seems justified. > (The other avenue for fixing it would be to try to give > the lookahead filter enough context to know when not to combine the > tokens, but I think that way will probably be unworkably convoluted.) This idea might work though. In particular, I think things would work nicely if we could make the filter return the special symbols like WITH_CASCADED only when the parser is in a state where such a symbol could be accepted. This appears to be possible if one is willing to get intimate enough with the internals of the Bison parser ... but that's something I'd prefer not to do, as it'd likely tie us to specific Bison versions to a much greater degree than we are now. At the moment, the number of cases where word pairs could act unexpectedly is small enough that I think we can just live with it. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly