(2010/01/24 12:29), Robert Haas wrote:
On Sat, Jan 23, 2010 at 1:45 PM, Bernd Helmle<maili...@oopsware.de>  wrote:
--On 14. Januar 2010 16:04:17 +0900 KaiGai Kohei<kai...@ak.jp.nec.com>
wrote:
This patch adds:

  List *find_column_origin(Oid relOid, const char *colName)

It returns the list of relation OIDs which originally defines the given
column. In most cases, it returns a list with an element. But, if the
column is inherited from multiple parent relations and merged during the
inheritance tree, the returned list contains multiple OIDs.
In this case, we have to forbid changing type and renaming to keep
correctness of the table definition.

Here's a slightly edited version of this patch from reviewing, fixing the
following:

* Fix a compiler warning by passing a pointer to skey to
systable_beginscan() (it's an array already)

* Edit some comments

The patch works as expected (at least, i don't see any remaining issues).
I'm going to mark this ready for committer.

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

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.

Basically, I don't think it is not a performance focused command,
because we may be able to assume ALTER TABLE RENAME TO is not much
frequent operations.

However, I'm interested in between two approaches.
I'll check both of them. Isn't is necessary to compare the vanilla code base,
because the matter is a bug to be fixed?

 http://archives.postgresql.org/message-id/4b41bb04.2070...@ak.jp.nec.com
 
http://archives.postgresql.org/message-id/a7739f610fb0bd89e310d...@[172.26.14.62]

Please wait for weekday, because I don't have physical (not virtual) machine
in my home.

Thanks,
--
KaiGai Kohei <kai...@kaigai.gr.jp>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to