Tom Lane:
The thing that was bothering me most about this is that I don't
understand why that's a useful check.  If I meant to type

        UPDATE mytab SET mycol = 42;

and instead I type

        UPDATEE mytab SET mycol = 42;

your proposed feature would catch that; great.  But if I type

        UPDATE mytabb SET mycol = 42;

it won't.  How does that make sense?  I'm not entirely sure where
to draw the line about what a "syntax check" should catch, but this
seems a bit south of what I'd want in a syntax-checking editor.

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.  ecpg could be a better model
to follow because it doesn't bring all the dependencies of the server
and so is much more likely to appear in a client-side installation.
It's kind of an ugly, unmaintained mess at the moment, sadly.

Would working with ecpg allow to get back a parse tree of the query to do stuff with that?

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.

Best,

Wolfgang



Reply via email to