How to use this tree-sitter in Zed editor?

[igorlidin]

Is there an easy way to use this tree-sitter grammar in Zed Editor for syntax highlighting of PL/PgSQL code? It looks so promising...

I tried to make a Zed language extension with this tree sitter as a grammar, it builds but fails to load silently, so I'm stuck.

[igorlidin]

Looks like #12 is the cause.

[gmr]

If you end up releasing something let me know. It was on my to-do list but haven't had time due to other obligations.

[AlexS778]

If you end up releasing something let me know. It was on my to-do list but haven't had time due to other obligations.

Well so far it works in Zed, we fixed wasm import error, but found other bugs in plpgsql part of the tree sitter:

1. If there are multiple plpgsql functions in a file, with $$ $$ tokens, a regex at line

   tree-sitter-postgres/postgres/grammar.js

   Line 4739 in 7113aeb

   dollar_quoted_string: _ => token(/\$[a-zA-Z_0-9]*\$[\s\S]*?\$[a-zA-Z_0-9]*\$/),

   is too broad. It can capture a $$ string and finish capturing at the last $$ string. so if we have multiple functions like this in a file:

DECLARE
...
$$
...
$$
END

DECLARE
...
$$
...
$$
END

it will capture a dollar string from the first $$ in a file, till the last $$ in a file, it won't capture $$ $$ in a function. Which leads to the whole file being treated as a $$ $$ string.

1.1 LANGUAGE PLPGSQL; is not treated like plpgsql injection, it's only LANGUAGE plpgsql; in lowercase -

tree-sitter-postgres/postgres/queries/injections.scm

Line 30 in 7113aeb

(#set! injection.language "plpgsql")

needs to be changed to (#match? @_lang "^[pP][lL][pP][gG][sS][qQ][lL]$") roughly, so it could match both PLPGSQL and plpgsql.

2. Biggest issue I found so far - no context for SQL regions. Current scanner stops SQL too early at keywords like NULL and INTO and etc. Example:

cat /Users/alexeyserbinov/Documents/db/schema/main/001.test.plpgsql
BEGIN
    IF _kind IS NULL OR length(_kind) = 0 THEN
        RAISE 'task.kind.bad: kind should not be NULL or empty'
            USING ERRCODE = 'ZZ001', CONSTRAINT = 'task.kind.bad';
    END IF;
END

../node_modules/.bin/tree-sitter parse --cst /Users/alexeyserbinov/Documents/db/schema/main/001.test.plpgsql
Warning: You have not configured any parser directories!
Please run `tree-sitter init-config` and edit the resulting
configuration file to indicate where we should look for
language grammars.

0:0  - 7:0    •source_file
0:0  - 5:3      •pl_block
0:0  - 0:5         kw_begin `BEGIN`
1:4  - 4:11       •proc_sect
1:4  - 4:11         •proc_stmt
1:4  - 4:11           •stmt_if
1:4  - 1:6               kw_if `IF`
1:7  - 1:16              sql_expression `_kind IS `
1:16 - 1:42             •ERROR
1:16 - 1:20                identifier `NULL`
1:42 - 1:46              kw_then `THEN`
2:8  - 3:66              proc_sect
2:8  - 3:66                proc_stmt
2:8  - 3:66                  stmt_raise
2:8  - 2:13                    kw_raise `RAISE`
2:14 - 2:63                    string_literal `'task.kind.bad: kind should not be NULL or empty'`
3:12 - 3:17                    kw_using `USING`
3:18 - 3:65                    raise_option
3:18 - 3:25                      kw_errcode `ERRCODE`
3:26 - 3:27                      "="
3:28 - 3:65                      sql_expression `'ZZ001', CONSTRAINT = 'task.kind.bad'`
3:65 - 3:66                   ";"
4:4  - 4:7              kw_end `END`
4:8  - 4:10             kw_if `IF`
4:10 - 4:11             ";"
5:0  - 5:3        kw_end `END`
/Users/alexeyserbinov/Documents/db/schema/main/001.test.plpgsql	Parse:    0.79 ms	   255 bytes/ms	(ERROR [1, 16] - [1, 42])

But I will create issues later for each of the problems and make PRs. Maybe later next week.

Otherwise parser and scanner is a solid work mate. Well done.

[gmr]

Thanks, one thing to look out for, that totally fell out of my head on the other PRs, is that it's codegen. Meaning when we update for Postgres 19 when it's released, individual changes that aren't made by way of the codegen will be lost.

I'll update the codegen to handle case insensitivity for the language (#15)

[gmr]

Evaluation of @AlexS778's three reports — both remaining bugs reproduce on main:

1.1 Case-insensitive LANGUAGE plpgsql — Addressed by #17. The (#match? @_lang "(?i)^plpgsql$") form is now baked into a new script/generate-injections.js, so the fix survives codegen regeneration (the original concern that motivated reverting #15).

1. Dollar-quoted string over-capture — Confirmed. With two $$ … $$ functions in one file, the parser collapses them into a single CreateFunctionStmt:

echo 'CREATE FUNCTION f1() RETURNS void LANGUAGE plpgsql AS $$ BEGIN END $$;
CREATE FUNCTION f2() RETURNS void LANGUAGE plpgsql AS $$ BEGIN END $$;' | tree-sitter parse
→ (CreateFunctionStmt [0,0]-[1,68]
     ...
     (dollar_quoted_string [0,49]-[1,68]))   ← spans both functions

Two flaws in dollar_quoted_string: _ => token(/\$[a-zA-Z_0-9]*\$[\s\S]*?\$[a-zA-Z_0-9]*\$/) (postgres/grammar.js:4739):

• Tree-sitter compiles token() regexes into a lexer DFA that does not honor non-greedy *?. The match is effectively greedy and consumes through the last $$ in the input.
• Even if *? worked, the regex doesn't require opening and closing tags to match — $a$body$b$ would match.

Fix path. Needs an external scanner for dollar_quoted_string in the postgres grammar (parallel to plpgsql/src/scanner.c): read $tag$, remember the tag, scan forward until a matching $tag$. This is how PostgreSQL itself parses dollar quotes. Substantial change — new external scanner, custom token type, binding updates — but the only correct fix.

2. plpgsql scanner stops too early at NULL/INTO/etc. — Confirmed. Reproduces verbatim on the example you posted: IF _kind IS NULL OR length(_kind) = 0 THEN parses with sql_expression = "_kind IS " and an ERROR node covering NULL OR length(_kind) = 0.

The scanner (plpgsql/src/scanner.c) keeps a flat list of "structural delimiter" keywords and stops on any of them at depth 0 — including null, into, all, next, query, etc. That's too aggressive: NULL is a delimiter only as a bare statement, not inside IS [NOT] NULL, = NULL, IN (..., NULL), COALESCE(..., NULL), etc. Same story for INTO (delimiter for SELECT … INTO var and EXECUTE … INTO var, but legal inside other expressions in principle).

Fix path. Make the scanner context-aware about a small set of "value-only" keywords (null, plus likely true/false if also affected): track the last non-comment, non-whitespace token at depth 0; don't treat null as a delimiter when it follows is, is not, =, <>, !=, in, ,, an operator, or ( (parens already raise depth, so the latter is implicit). Statement-start NULL; still stops correctly because the scanner is only invoked when SQL_BODY is a valid symbol — not at statement-start.

INTO is trickier and probably needs its own pass — SELECT col INTO var FROM t requires stopping at INTO, but only after a select-list has been consumed. Worth a separate issue/PR.

Recommendation: treat #2 and #3 as separate tickets — each is non-trivial (#2 = new external scanner; #3 = scanner refactor with new tests). Happy to take either if useful.