From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Josef Šimánek <josef(dot)simanek(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] Add --syntax to postgres for SQL syntax checking |
Date: | 2024-02-25 22:24:24 |
Message-ID: | 64f4c421-12ea-4801-ba0a-9e227b6014bb@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/15/23 16:38, Josef Šimánek wrote:
> pá 15. 12. 2023 v 16:32 odesílatel David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> napsal:
>>
>> On Fri, Dec 15, 2023 at 8:20 AM Josef Šimánek <josef(dot)simanek(at)gmail(dot)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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2024-02-25 22:32:52 | Re: Logging parallel worker draught |
Previous Message | Tomas Vondra | 2024-02-25 21:58:52 | Re: Making the initial and maximum DSA segment sizes configurable |