Skip site navigation (1) Skip section navigation (2)

Re: BUG #5856: pg_attribute.attinhcount is not correct.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Naoya Anzai <anzai-naoya(at)mxu(dot)nes(dot)nec(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: BUG #5856: pg_attribute.attinhcount is not correct.
Date: 2011-04-04 01:53:57
Message-ID: BANLkTimcxnodo2E24q66cwVf5HYfQt9aQQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
On Fri, Apr 1, 2011 at 12:56 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Thu, Mar 31, 2011 at 11:11:49AM -0400, Robert Haas wrote:
>> On Thu, Mar 31, 2011 at 6:06 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> >> I think this is a manifestation the same problem mentioned here:
>> >>
>> >> http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=31b6fc06d83c6de3644c8f2921eb7de0eb92fac3
>> >>
>> >> I believe this requires some refactoring to fix. ?It would be good to do that.
>> >
>> > The best way I can see is to make ATExecAddColumn more like ATExecDropColumn,
>> > ATAddCheckConstraint, and ATExecDropConstraint. ?Namely, recurse at Exec-time
>> > rather than Prep-time, and cease recursing when we satisfy the ADD COLUMN with a
>> > merge. ?Did you have something else in mind?
>>
>> I had exactly what you just said in mind.
>
> Patch attached, then.

Committed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-04-04 03:23:48
Subject: Re: cast from integer to money
Previous:From: Robert HaasDate: 2011-04-03 23:57:34
Subject: Re: maximum digits for NUMERIC

pgsql-bugs by date

Next:From: Jan-Erik LärkaDate: 2011-04-04 16:34:21
Subject: Non Win/*nix UTF-8 codepage not known to PostgreSQL developers?!
Previous:From: Tom LaneDate: 2011-04-03 16:46:49
Subject: Re: BUG #5964: doc bug -- copy does not take "format" literal

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group