2010/1/27 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)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

In response to

• Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns at 2010-01-28 01:13:49 from KaiGai Kohei

Responses

• Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns at 2010-01-29 00:13:02 from KaiGai Kohei

pgsql-hackers by date

Next:	From: Tom Lane	Date: 2010-01-28 15:46:47
	Subject: Re: pgsql: Define INADDR_NONE on Solaris when it's missing.
Previous:	From: Tim Bunce	Date: 2010-01-28 15:46:12
	Subject: Add on_perl_init and proper destruction to plperl UPDATED [PATCH]