Re: Rearranging ALTER TABLE to avoid multi-operations bugs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Rearranging ALTER TABLE to avoid multi-operations bugs
Дата
Msg-id 1616.1562032829@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Rearranging ALTER TABLE to avoid multi-operations bugs  (movead li <movead.li@highgo.ca>)
Ответы Re: Rearranging ALTER TABLE to avoid multi-operations bugs  (Thomas Munro <thomas.munro@gmail.com>)
Re: Rearranging ALTER TABLE to avoid multi-operations bugs  (movead li <movead.li@highgo.ca>)
Список pgsql-hackers
movead li <movead.li@highgo.ca> writes:
> I applied the 'alter-table-with-recursive-process-utility-calls-wip.patch'
> on the master(e788e849addd56007a0e75f3b5514f294a0f3bca). And 
> when I test the cases, I find it works well on 'alter table t1 add column
> f2 int not null, alter column f2 add generated always as identity' case, 
> but it doesn't work on #14827, #15180, #15670, #15710.

This review seems not very on-point, because I made no claim to have fixed
any of those bugs.  The issue at the moment is how to structure the code
to allow ALTER TABLE to call other utility statements --- or, if we aren't
going to do that as Robert seems not to want to, what exactly we're going
to do instead.

The patch at hand does fix some ALTER TABLE ... IDENTITY bugs, because
fixing those doesn't require any conditional execution of utility
statements.  But we'll need infrastructure for such conditional execution
to fix the original bugs.  I don't see much point in working on that part
until we have some agreement about how to handle what this patch is
already doing.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Transactions involving multiple postgres foreignservers, take 2
Следующее
От: Michael Meskes
Дата:
Сообщение: Re: [PATCH] memory leak in ecpglib