On Tue, May 26, 2020 at 4:28 AM Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 2020-05-25 21:09, Mark Dilger wrote: > > I don't think it moves the needle too much, either. But since your patch > > is entirely a refactoring patch and not a feature patch, I thought it would > > be fair to ask larger questions about how the code should be structured. I > > like using enums and switch statements and getting better error messages, > > but there doesn't seem to be any fundamental reason why that should be in > > the command execution step. It feels like a layering violation to me. > > Most utility commands don't have an intermediate parse analysis pass. > They just go straight from the grammar to the execution. Maybe that > could be rethought, but that's the way it is now.
I think it can and should be rethought at some point. The present split leads to a lot of weird coding. We've had security vulnerabilities that were due to things like passing the same RangeVar to two different places, leading to two different lookups for the name that could be induced to return different OIDs. It also leads to a lot of fuzzy thinking about where locks are taken, in which order, and how many times, and with what strength. The code for queries seems to have been thought through a lot more carefully, because the existence of prepared queries makes mistakes a lot more noticeable. I hope some day someone will be motivated to improve the situation for DDL as well, though it will probably be a thankless task. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
