Re: [PATCH] Add --syntax to postgres for SQL syntax checking - Mailing list pgsql-hackers

From Josef Šimánek
Subject Re: [PATCH] Add --syntax to postgres for SQL syntax checking
Date
Msg-id CAFp7Qwrga7vo9acCFG+Aar_B251+1xJz_CLQN5vic-ZWsh9yeQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Add --syntax to postgres for SQL syntax checking  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: [PATCH] Add --syntax to postgres for SQL syntax checking
List pgsql-hackers
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 reference
CLIimplementation 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.

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.

> David J.



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: [PATCH] Add --syntax to postgres for SQL syntax checking
Next
From: "Tristan Partin"
Date:
Subject: Re: Add --check option to pgindent