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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <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-04 04:18:26
Message-ID: 22211.1262578706@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 2010/1/3 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> if (number_of_attribute_origin(myrelid, oldattname) > 1)
>>   ereport(ERROR, ...);
>> 
>> Am I missing something?

> That sounds about right to me,

It looks remarkably inefficient to me.  Do you propose to search the
entire database's inheritance tree to derive that number?  And do it
over again at each child table?  The method I suggested would allow the
necessary information to be extracted during the initial search for
child tables, which we have to do anyway.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-01-04 04:19:28
Subject: Re: patch - per-tablespace random_page_cost/seq_page_cost
Previous:From: Tom LaneDate: 2010-01-04 04:12:39
Subject: Re: Buffer statistics for pg_stat_statements

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