Re: Rearranging ALTER TABLE to avoid multi-operations bugs

On Wed, May 29, 2019 at 5:52 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hm ... I'm not exactly clear on why that would be a superior solution.
> It would imply that standalone CREATE INDEX etc would call into the
> ALTER TABLE framework --- how is that not equally a layering violation?

Well, the framework could be renamed to something more general, I
suppose, but I don't see a *layering* concern.

From my point of view, the DDL code doesn't do a great job separating
parsing/parse analysis from optimization/execution. The ALTER TABLE
stuff is actually pretty good in this regard. But when you build
something that is basically a parse tree and pass it to some other
function that thinks that parse tree may well be coming straight from
the user, you are not doing a good job distinguishing between a
statement and an action which that statement may caused to be
performed.

> Also, recursive ProcessUtility cases exist independently of this issue,
> in particular in CreateSchemaCommand. My worry about my patch upthread
> is not really that it introduces another one, but that it doesn't do
> anything towards providing a uniform framework/notation for all these
> cases.

I'm not really sure I understand this.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company