Query builder editor's autocomplete context awareness

[depombo]

No description provided.

[mtp1376]

I think we need an implementation of PostgreSQL lexer to be able to do this.

[dfellis]

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:

1. Fork the repo and convert the binding to one based on a WASM compilation of the C parser, allowing us to run it client side.
2. Create a new project that uses 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.)
3. We grab our high perf parser code from Alan (I call it high perf because in Javascript it's faster than ANTLR even in its native Java, though the API is more awkward, tbh) and write a parser for Postgres SELECT, INSERT, UPDATE, and DELETE statements, and just fall back to the current prefix matching on all keywords on parse failure.
4. Find an existing JS SQL parser that may or may not perfectly match Postgres and go with that, possibly failing more often.
5. Implement a super simple line-by-line-only parser that only narrows down the set of keywords based on the class of the keyword (column name, table name, value, etc) expected since 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).