Re: Rearranging ALTER TABLE to avoid multi-operations bugs

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, May 26, 2019 at 6:24 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Anybody have thoughts about a different way to approach it?

> I mean, in an ideal world, I think we'd never call back out to
> ProcessUtility() from within AlterTable(). That seems like a pretty
> clear layering violation. I assume the reason we've never tried to do
> better is a lack of round tuits and/or sufficient motivation.

> In terms of what we'd do instead, I suppose we'd try to move as much
> as possible inside the ALTER TABLE framework proper and have
> everything call into that.

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?

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.

regards, tom lane