ne 25. 2. 2024 v 23:24 odesílatel Tomas Vondra <tomas.von...@enterprisedb.com> napsal: > > > > On 12/15/23 16:38, Josef Šimánek wrote: > > pá 15. 12. 2023 v 16:32 odesílatel David G. Johnston > > <david.g.johns...@gmail.com> napsal: > >> > >> On Fri, Dec 15, 2023 at 8:20 AM Josef Šimánek <josef.sima...@gmail.com> > >> wrote: > >>> > >>> (parser is not available > >>> in public APIs of postgres_fe.h or libpq). > >> > >> > >> What about building "libpg" that does expose and exports some public APIs > >> for the parser? We can include a reference CLI implementation for basic > >> usage of the functionality while leaving the actual language server > >> project outside of core. > > > > Language server (LSP) can just benefit from this feature, but it > > doesn't cover all possibilities since LSP is meant for one purpose -> > > run in developer's code editor. Actual syntax check is more generic, > > able to cover CI checks and more. I would not couple this feature and > > LSP, LSP can just benefit from it (and it is usually built in a way > > that uses other tools and packs them into LSP). Exposing this kind of > > SQL check doesn't mean something LSP related being implemented in > > core. LSP can just benefit from this. > > > > I don't know enough about LSP to have a good idea how to implement this > for PG, but my assumption would be we'd have some sort of library > exposing "parser" to frontend tools, and also an in-core binary using > that library (say, src/bin/pg_syntax_check). And LSP would use that > parser library too ... > > I think there's about 0% chance we'd add this to "postgres" binary.
Exposing parser to frontend tools makes no sense to me and even if it would, it is a huge project not worth to be done just because of syntax check. I can update the patch to prepare a new binary, but still on the backend side. This syntax check should be equivalent to running a server locally, running a query and caring only about parsing part finished successfully. In my thinking, this belongs to backend tools. > > Exposing parser to libpg seems good idea, but I'm not sure how simple > > that could be done since during my journey I have found out there are > > a lot of dependencies which are not present in usual frontend code per > > my understanding like memory contexts and removal of those > > (decoupling) would be huge project IMHO. > > > > You're right the grammar/parser expects a lot of backend infrastructure, > so making it available to frontend is going to be challenging. But I > doubt there's a better way than starting with gram.y and either removing > or adding the missing pieces (maybe only a mock version of it). > > I'm not a bison expert, but considering your goal seems to be a basic > syntax check, maybe you could simply rip out most of the bits depending > on backend stuff, or maybe replace them with some trivial no-op code? > > But as Tom mentioned, the question is how far gram.y gets you. There's > plenty of ereport(ERROR) calls in src/backend/parser/*.c our users might > easily consider as parse errors ... > > > regards > > -- > Tomas Vondra > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company
