This PR fixes #4308 and #4315. The issue was caused by adding in rules for PL/PGSQL into PostgreSQL. These rules were added to parse function bodies, but the changes also affected parsing of PostgreSQL. The problem is that the lexing rules overlap between the two languages. You cannot simply add two non-disjoint lexer rules together because you then have an enormous task in trying to clarify the PostgreSQL parser rules, least of which is the ambiguity. This is probably why there's a collection of tests that fail in the examples.errors/ directory.
All parser rules for PL/PGSQL were removed.
As much as I can find, all the lexer symbols for PL/PGSQL were removed from the lexer grammar.
The desc.xml was updated to specify which files to parse (i.e., *.sql).
collabel was renamed to colLabel to be closer to the official source for the grammar, gram.y.
teverett
commented
1 week ago
This PR fixes #4308 and #4315. The issue was caused by adding in rules for PL/PGSQL into PostgreSQL. These rules were added to parse function bodies, but the changes also affected parsing of PostgreSQL. The problem is that the lexing rules overlap between the two languages. You cannot simply add two non-disjoint lexer rules together because you then have an enormous task in trying to clarify the PostgreSQL parser rules, least of which is the ambiguity. This is probably why there's a collection of tests that fail in the examples.errors/ directory.
collabelwas renamed tocolLabelto be closer to the official source for the grammar, gram.y.The ambiguity no longer exists.
trparse --ambig -i "SELECT 'trailing' AS first;" | trtree -ayields no ambiguity trees.The plan is to re-add parsing of function bodies with a completely separate grammar for pl/pgsql later.