Re: Rearranging ALTER TABLE to avoid multi-operations bugs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Rearranging ALTER TABLE to avoid multi-operations bugs
Дата
Msg-id 41500.1559166722@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Rearranging ALTER TABLE to avoid multi-operations bugs  (Robert Haas <robertmhaas@gmail.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Runtime Partition Pruning