(2010/01/27 23:29), Robert Haas wrote:
> 2010/1/27 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> The attached patch is revised one based on the V3 approach.
>> The only difference from V3 is that it also applies checks on the
>> AT_AlterColumnType option, not only renameatt().
>
> I think I was clear about what the next step was for this patch in my
> previous email, but let me try again.
>
> http://archives.postgresql.org/pgsql-hackers/2010-01/msg02407.php
>
> See also Tom's comments here:
>
> http://archives.postgresql.org/pgsql-hackers/2010-01/msg00110.php
>
> I don't believe that either Tom or I are prepared to commit a patch
> based on this approach, at least not unless someone makes an attempt
> to do it the other way and finds an even more serious problem.  If
> you're not interested in rewriting the patch along the lines Tom
> suggested, then we should just mark this as Returned with Feedback and
> move on.

The V3/V5 patch was the rewritten one based on the Tom's comment, as is.
It counts the expected inhcount at the first find_all_inheritors() time
at once, and it compares the pg_attribute.attinhcount.
(In actually, find_all_inheritors() does not have a capability to count
the number of merged from a common origin, so I newly defined the
find_all_inheritors_with_inhcount().)

Am I missing something?

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

• Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns at 2010-01-27 14:29:06 from Robert Haas

Responses

• Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns at 2010-01-27 20:42:45 from Robert Haas

pgsql-hackers by date

Next:	From: Kevin Grittner	Date: 2010-01-27 15:27:22
	Subject: Re: C function accepting/returning cstring vs. text
Previous:	From: Ivan Sergio Borgonovo	Date: 2010-01-27 15:17:24
	Subject: Re: C function accepting/returning cstring vs. text