st 15. 5. 2024 v 21:28 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal: > > Robert Haas <robertmh...@gmail.com> writes: > > 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. ... > > > But I don't understand the idea that the concept doesn't make sense. > > Sorry: "make sense" was a poorly chosen phrase there. What I was > doubting, and continue to doubt, is that 100% checking of what > you can check without catalog access and 0% checking of the rest > is a behavior that end users will find especially useful.
But that's completely different feature which is not exclusive and shouldn't block this other feature to do only exactly as specified. > > 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. > > I'm less enthusiatic about this than you are. I think it would likely > produce a slower and less maintainable system. Slower because we'd > need more passes over the query: what parse analysis does today would > have to be done in at least two separate steps. Less maintainable > because knowledge about certain things would end up being more spread > around the system. Taking your example of getting syntax checking to > recognize invalid EXPLAIN keywords: right now there's just one piece > of code that knows what those options are, but this'd require two. > Also, "run the first set of checks and then decide whether to proceed > further" seems like optimizing the system for broken queries over > valid ones, which I don't think is an appropriate goal. > > Now, I don't say that there'd be *no* benefit to reorganizing the > system that way. But it wouldn't be an unalloyed win, and so I > share your bottom line that the costs would be out of proportion > to the benefits. > > regards, tom lane
