Open jaidetree opened 7 months ago
The short version is that this library parses SQL across dialects, but does not parse specific procedural elaborations, like Postgres' PL/pgSQL or Oracle's PL/SQL. CREATE FUNCTION
is standard SQL, but up until recently the standard said that function bodies are strings, and not even necessarily SQL strings at that (viz. pl/Python). BEGIN ATOMIC
changed that for SQL functions but not procedural languages -- those dollar quotes delimit a string. We parse the function body because it's probably SQLish, but as you see the parser doesn't know what to do with IF
or RAISE
. It should know what to do with RETURN
, and if you had a few more standard statements after your IF
block the parser might recover since tree-sitter tries to be generous, but there aren't any guarantees. It bugs me too; there's been a little discussion, but what you see is where we got. I think there's probably a case for giving the basics like IF
a shot, honestly; we can always decline if it turns out to really balloon the library size.
Given the following Postgres SQL function:
Syntax highlighting completely stops for the rest of the file if I keep that semicolon after the first query that ends with
LIMIT 1;
If I remove that semicolon after the first query the syntax highlighter continues highlighting the file but the syntax is invalid and running the migration fails.
Any ideas what's causing that? Happy to help with a PR to fix but will need some guidance. Though as far as I know, I'm just using this wrong 😅