Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: KaiGai Kohei <kaigai@ak.jp.nec.com>
Cc: KaiGai Kohei <kaigai@kaigai.gr.jp>, Bernd Helmle <mailings@oopsware.de>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, Thom Brown <thombrown@gmail.com>, Alvaro Herrera <alvherre@commandprompt.com>
Date: 2010-01-28T15:46:44Z
Lists: 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