Re: Rearranging ALTER TABLE to avoid multi-operations bugs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Rearranging ALTER TABLE to avoid multi-operations bugs
Дата
Msg-id 23856.1567527697@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Rearranging ALTER TABLE to avoid multi-operations bugs  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom: CFbot says this patch doesn't apply anymore.  Could you please
> rebase?

Robert doesn't like the whole approach [1], so I'm not seeing much
point in rebasing the current patch.  The idea I'd been thinking
about instead was to invent a new AlterTableType enum value for
each type of utility command that we can currently generate as a
result of parse analysis of ALTER TABLE, then emit those currently
separate commands as AlterTableCmds with "def" pointing to the
relevant utility-command parsetree, and then add code to ALTER
TABLE to call the appropriate execution functions directly rather
than via ProcessUtility.  (This will add significantly more code
than what I had, and I'm not convinced it's better, just different.)

I haven't gotten to that yet, and now that the CF has started I'm
not sure if I'll have time for it this month.  Maybe we should just
mark the CF entry as RWF for now, or push it out to the next fest.

            regards, tom lane

[1] https://www.postgresql.org/message-id/CA%2BTgmoa3FzZvWriJmqquvAbf8GxrC9YM9umBb18j5M69iuq9bg%40mail.gmail.com



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Rearranging ALTER TABLE to avoid multi-operations bugs
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Patch: New GUC prepared_statement_limit to limit memory used byprepared statements