Thank you for your reply. I am aware about these conflicts, but thank you for the explanation.
My question is specific to Postgres. Do we have a set of guidelines we keep in mind while writing grammar rules while introducing new features to postgres?
One such suggestion or rule for example is the Postgres does not support Postfix operators. So whenever a new feature is introduced developers make sure that they do not add a postfix operators in their grammar. Just like that are there any other further rules or suggestions compiled by post hackers and maintainers?
> Is there a guidebook, any guidelines for writing grammar in Postgres, or any suggestions to keep in mind? > Do we have a set of guidelines to write production rules in gram.y (for the Bison Parser Generator) to make the grammar conflict-free and extendible in the future?
I'm far from being an expert in compilers but my dilettante understanding is that there are two types of conflicts. Shift/reduce conflicts are resolved with operator priorities (e.g. does 1+2*3 mean 1+(2*3) or (1+2)*3). Reduce/reduce conflict means a "real" conflict and Flex/Bison should (?) warn you about those. They will not happen though as long as you use common sense. On top of that note that generally PostgreSQL follows SQL standard.
If you look for guidelines "flex & bison" by John Levine [1] and "Compilers: Principles, Techniques, and Tools" by Aho, Ullman et al [2] are good reads.
I'm not entirely sure if it answers your question but I hope that it's helpful.
