Re: some grammar refactoring

On Tue, May 26, 2020 at 4:28 AM Peter Eisentraut
<peter.eisentraut@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
featurepatch, I thought it would be fair to ask larger questions about how the code should be structured.  I like using
enumsand switch statements and getting better error messages, but there doesn't seem to be any fundamental reason why
thatshould 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