Обсуждение: Grammar guidelines in Postgres
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?
Hi, > 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 grammarconflict-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. [1]: https://www.amazon.com/Flex-Bison-John-R-Levine/dp/0596155972/ [2]: https://www.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811/ -- Best regards, Aleksander Alekseev
Hi, > 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 introducingnew features to postgres? > > One such suggestion or rule for example is the Postgres does not support Postfix operators. So whenever a new feature isintroduced developers make sure that they do not add a postfix operators in their grammar. Just like that are there anyother further rules or suggestions compiled by post hackers and maintainers? I believe you wanted to reply to the mailing list, not to me directly. Please use the "Reply to All" button. Do the postfix operators you mention exist in the SQL standard? -- Best regards, Aleksander Alekseev
Greetings,
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?
On Thu, Jul 4, 2024 at 2:47 AM Aleksander Alekseev <aleksander@timescale.com> wrote:
Hi,
> 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.
[1]: https://www.amazon.com/Flex-Bison-John-R-Levine/dp/0596155972/
[2]: https://www.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811/
--
Best regards,
Aleksander Alekseev
Harjyot Bagga <hsbagga28.dev@gmail.com> writes:
> 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?
[ shrug... ] If you try to re-introduce postfix operators you'll get
a ton of shift-reduce conflicts. We have a hard rule that such
conflicts are not allowed, even though Bison can be told to ignore
them. Beyond that, there's not much.
regards, tom lane