On Wed, May 15, 2024 at 2:39 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
I don't agree with this, actually. The first wrong example can never be valid, while the second one can be valid given the right table definitions. That lines up quite nicely with the distinction between parsing and parse analysis. There is a problem with actually getting all the way there, I'm fairly sure, because we've got thousands of lines of gram.y and thousands of lines of parse analysis code that weren't all written with the idea of making a crisp distinction here. For example, I'd like both EXPLAIN (WAFFLES) SELECT 1 and EXPLAIN WAFFLES SELECT 1 to be flagged as syntactically invalid, and with things as they are that would not happen. Even for plannable statements I would not be at all surprised to hear that there are a bunch of corner cases that we'd get wrong. But I don't understand the idea that the concept doesn't make sense. I think it is perfectly reasonable to imagine a world in which the initial parsing takes care of reporting everything that can be determined by static analysis without knowing anything about catalog contents, and parse analysis checks all the things that require catalog access, and you can run the first set of checks and then decide whether to proceed further. I think if I were designing a new system from scratch, I'd definitely want to set it up that way, and I think moving our existing system in that direction would probably let us clean up a variety of warts along the way. Really, the only argument I see against it is that getting from where we are to there would be a gigantic amount of work for the value we'd derive. -- Robert Haas EDB: http://www.enterprisedb.com