Definitely. Of course, I can't promise that we can make it work properly, but it's high on our todo list.
steinroe is a very fast man: https://github.com/supabase-community/postgres-language-serv...
Thanks for the report. Hmm, we have some tests for CTEs, so at least we tried to support them. I'll file an issue with your exact query.
Good question. If you rarely change your db, it'll probably not be as useful. But some platforms (such as Supabase) rely on many parts of Postgres. You use INSERT hooks to trigger queue insertions, Row Level Security…
Thanks for the feedback. Good points, we'll improve the README. Regarding your questions: 1. It's currently only for SQL statements, but we'll work on function bodies and PL/pgSQL soon. 2. Exactly, we follow the the…
co-author here: The most interesting part is probably the parsing of SQL files. The first issue is that the Postgres parser is complex and always changing, so you can't really roll your own parser to parse SQL. The…
Definitely. Of course, I can't promise that we can make it work properly, but it's high on our todo list.
steinroe is a very fast man: https://github.com/supabase-community/postgres-language-serv...
Thanks for the report. Hmm, we have some tests for CTEs, so at least we tried to support them. I'll file an issue with your exact query.
Good question. If you rarely change your db, it'll probably not be as useful. But some platforms (such as Supabase) rely on many parts of Postgres. You use INSERT hooks to trigger queue insertions, Row Level Security…
Thanks for the feedback. Good points, we'll improve the README. Regarding your questions: 1. It's currently only for SQL statements, but we'll work on function bodies and PL/pgSQL soon. 2. Exactly, we follow the the…
co-author here: The most interesting part is probably the parsing of SQL files. The first issue is that the Postgres parser is complex and always changing, so you can't really roll your own parser to parse SQL. The…