Re: Rearranging ALTER TABLE to avoid multi-operations bugs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rearranging ALTER TABLE to avoid multi-operations bugs
Date
Msg-id 41500.1559166722@sss.pgh.pa.us
Whole thread Raw
In response to Re: Rearranging ALTER TABLE to avoid multi-operations bugs  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Rearranging ALTER TABLE to avoid multi-operations bugs  (Robert Haas <robertmhaas@gmail.com>)
Re: Rearranging ALTER TABLE to avoid multi-operations bugs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, May 26, 2019 at 6:24 PM Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Runtime Partition Pruning