Re: [PATCH] Add --syntax to postgres for SQL syntax checking

On 12/15/23 16:38, Josef Šimánek wrote:
> pá 15. 12. 2023 v 16:32 odesílatel David G. Johnston
> <david.g.johnston@gmail.com> napsal:
>>
>> On Fri, Dec 15, 2023 at 8:20 AM Josef Šimánek <josef.simanek@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
referenceCLI implementation for basic usage of the functionality while leaving the actual language server project
outsideof 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 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