=?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= <josef.sima...@gmail.com> writes: > I'm not sure everyone in this thread understands the reason for this > patch, which is clearly my fault, since I have failed to explain. Main > idea is to make a tool to validate query can be parsed, that's all. > Similar to running "EXPLAIN query", but not caring about the result > and not caring about the DB structure (ignoring missing tables, ...), > just checking it was successfully executed. This definitely belongs to > the server side and not to the client side, it is just a tool to > validate that for this running PostgreSQL backend it is a "parseable" > query.
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. The big knock on doing this client-side is that there might be version skew compared to the server you're using --- but if you are not doing anything beyond a grammar-level check then your results are pretty approximate anyway, ISTM. We've not heard anything suggesting that version skew is a huge problem for ecpg users. regards, tom lane