Re: [PATCH] Add --syntax to postgres for SQL syntax checking
От | walther@technowledgy.de |
---|---|
Тема | Re: [PATCH] Add --syntax to postgres for SQL syntax checking |
Дата | |
Msg-id | 43eeedd7-51a6-4520-8848-247341566e3d@technowledgy.de обсуждение исходный текст |
Ответ на | Re: [PATCH] Add --syntax to postgres for SQL syntax checking (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] Add --syntax to postgres for SQL syntax checking
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: