(2010/01/24 12:29), Robert Haas wrote:
> On Sat, Jan 23, 2010 at 1:45 PM, Bernd Helmle<mailings(at)oopsware(dot)de> wrote:
>> --On 14. Januar 2010 16:04:17 +0900 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>
>>> 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
>> * 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:
> 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
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?
Please wait for weekday, because I don't have physical (not virtual) machine
in my home.
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
In response to
pgsql-hackers by date
|Next:||From: Jaime Casanova||Date: 2010-01-24 05:06:38|
|Subject: Re: further explain changes|
|Previous:||From: KaiGai Kohei||Date: 2010-01-24 03:40:37|
|Subject: Re: restructuring "alter table" privilege checks|