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

Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org, Thom Brown <thombrown(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Date: 2010-01-24 12:13:44
Message-ID: FCD5B48597C9C131BE1A3488@amenophis (view raw or flat)
Thread:
Lists: pgsql-hackers

--On 23. Januar 2010 22:29:23 -0500 Robert Haas <robertmhaas(at)gmail(dot)com> 
wrote:

> I don't think this is ready for committer, becauseTom previously
> objected to the approach taken by this patch here, and no one has
> answered his objections:
>
> http://archives.postgresql.org/pgsql-hackers/2010-01/msg00144.php
>

Ugh, i thought KaiGai's revised patch here

<http://archives.postgresql.org/message-id/4B41BB04.2070609@ak.jp.nec.com>

was in response to Tom's complaint, since it modifies the method to identify
column origins by recursivly scanning pg_inherits with its current 
inhrelid.


> I think someone needs to figure out what the worst-case scenario for
> this is performance-wise and submit a reproducible test case with
> benchmark results.  In the meantime, I'm going to set this to Waiting
> on Author.

Makes sense.

-- 
Thanks

	Bernd

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-01-24 12:45:18
Subject: Re: further explain changes
Previous:From: Greg StarkDate: 2010-01-24 11:22:55
Subject: Re: further explain changes

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