| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | walther(at)technowledgy(dot)de |
| Cc: | Josef Šimánek <josef(dot)simanek(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, 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-05-15 19:01:25 |
| Message-ID: | 1815338.1715799685@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
walther(at)technowledgy(dot)de writes:
> Tom Lane:
>> BTW, if you do feel that a pure grammar check is worthwhile, you
>> should look at the ecpg preprocessor, which does more or less that
>> with the SQL portions of its input.
> Would working with ecpg allow to get back a parse tree of the query to
> do stuff with that?
No, ecpg isn't interested in building a syntax tree.
> This is really what is missing for the ecosystem. A libpqparser for
> tools to use: Formatters, linters, query rewriters, simple syntax
> checkers... they are all missing access to postgres' own parser.
To get to that, you'd need some kind of agreement on what the syntax
tree is. I doubt our existing implementation would be directly useful
to very many tools, and even if it is, do they want to track constant
version-to-version changes?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-05-15 19:03:02 | Re: [PATCH] Add --syntax to postgres for SQL syntax checking |
| Previous Message | David G. Johnston | 2024-05-15 19:01:18 | Re: add function argument names to regex* functions. |