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
|
Список | 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 по дате отправления: