Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Дата
Msg-id 603c8f071001280746j53e5383ev63254e041072d5a5@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Ответы Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Список pgsql-hackers
2010/1/27 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> Hmm, indeed, this logic (V3/V5) is busted.
>
> The idea of V4 patch can also handle this case correctly, although it
> is lesser in performance.
> I wonder whether it is really unacceptable cost in performance, or not.
> Basically, I assume ALTER TABLE RENAME/TYPE is not frequent operations,
> and I don't think this bugfix will damage to the reputation of PostgreSQL.
>
> Where should we go on the next?

Isn't the problem here just that the following comment is 100% wrong?
               /*                * Unlike find_all_inheritors(), we need to walk on
child relations                * that have diamond inheritance tree, because this
function has to                * return correct expected inhecount to the caller.                */

It seems to me that the right solution here is to just add one more
argument to find_all_inheritors(), something like List
**expected_inh_count.

Am I missing something?

...Robert


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

Предыдущее
От: Tim Bunce
Дата:
Сообщение: Add on_perl_init and proper destruction to plperl UPDATED [PATCH]
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Streaming replication, and walsender during recovery