Open depombo opened 1 year ago
We use one in the engine itself, it's called pgsql-parser
. It's a binding to the real C parser, though, so to use it in the dashboard we need to access it via an API call, which may introduce too much latency to be useful.
Possible solutions on that front:
pgsql-parser
only as a guide to create a WASM compilation of the C parser. (Similar to above, but if we decide that it's more work to convert the project than to greenfield one.)SELECT
, INSERT
, UPDATE
, and DELETE
statements, and just fall back to the current prefix matching on all keywords on parse failure.SELECT
statements unfortunately put the column selection before the table selection so restricting to just columns of a table you don't know yet is impossible.I'm sure there's others, but we could also consider this list backwards in order of improvements we can make, and decide on a set to follow (eg, first 5, then 4, then 2).
I think we need an implementation of PostgreSQL lexer to be able to do this.