Fabien COELHO <[EMAIL PROTECTED]> writes: > I would not like to break postgresql portability with other parser > generators.
I agree with Bruce's opinion that this is a nonissue. In particular I'd point out that the current grammar is already too big for any known yacc clone besides bison (even with bison you need a very recent version), and your proposed changes are going to make the grammar a whole lot larger yet, at least in terms of states and actions. Even if there was any usefulness to supporting other yacc clones, the odds of making one work seem minuscule. > Using some non standard undocumented API would not help other people who > would like to touch the parser. It would help them a *lot* if it meant that they didn't have to be aware of this stuff in order to do anything at all with the grammar. My fundamental objection to this proposal continues to be that it will make the grammar unreadable and unmaintainable. If we could push the error message generation issues into a subroutine of yyerror() and not touch the grammar rules at all, the chances of getting this accepted would rise about a thousand percent. The sample hints you show in another message still aren't impressing me much, but in any case they look like they only depend on being able to see what grammar symbols can follow the current point. The last time I studied this stuff (which was quite a while back) the follow set was something an LR parser generator would have to compute anyway. I don't know whether bison's internal tables expose that set in any useful fashion, but it surely seems worth a look. regards, tom lane PS: another reason for doing it that way is that I suspect your current approach is a dead end anyhow. You've already hit one blocker problem where you got reduce/reduce errors when you tried to insert state-recording actions, and you've only gone as far as hinting the very first symbol, which is hardly one of the more complex parts of the grammar. There are large parts of the grammar that only manage to avoid ambiguity by the skin of their teeth --- I don't believe you'll be able to do anything of this sort in those areas without breaking it. Take a look at SelectStmt and subsidiary productions as an example ... that's a fragile bit of work that took a long time to get right. ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org