Is it too late to ask for version option for parsing?

[ReinsBrain]

I have various versions of postgresql in my environment so i'd love to be able to choose which version of the postgres parser to parse with.

[lfittl]

@ReinsBrain Good question.

One challenge with this is that it significantly increases the effort to maintain the parser (as one would need to ensure everything works correctly on multiple versions). One can see that this is already quite some effort, since its taken a while to get Postgres 13 support (due to be released in a week or so).

Generally the Postgres project is good about backwards compatibility for SQL syntax too.

Do you have specific situations you are concerned about where you think an older parser would be required for compatibility?

[ReinsBrain]

@lfittl - i'd agree, postgresql is great with backwards compatibility... although i have scripts that i want to pre-check which will pass parsing on later version but not on earlier versions. For example, i don't want to allow JSONB type on 9.4 or the modern table partition syntax on 9.6. I understand what a large effort this must be and i understand if older versions cannot be priority. Although, I hope it might make sense to allow subsequent parser versions to extend earlier ones so that it might be an option going forward. Thanks for the hard work :)

[lfittl]

@ReinsBrain Got it, makes sense re: checking whether syntax is compatible.

Technically it might be feasible to use the existing extraction logic (see scripts/ folder) on older versions, but it'll a little bit of extra work for each version to adjust the referenced symbols/filenames, etc.

For now this is not something in scope for this project, but you are of course welcome to re-use the extraction logic yourself. Also, for future Postgres versions, the intent is to have reliable yearly releases going forward (with each Postgres major release), so that should lead to a point in a few years where we have a parser branch for each Postgres release that is not yet EOL :)