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

Поиск
Список
Период
Сортировка
От KaiGai Kohei
Тема Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Дата
Msg-id 4B5BC313.8020301@kaigai.gr.jp
обсуждение исходный текст
Ответ на Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
(2010/01/24 12:29), Robert Haas wrote:
> On Sat, Jan 23, 2010 at 1:45 PM, Bernd Helmle<mailings@oopsware.de>  wrote:
>> --On 14. Januar 2010 16:04:17 +0900 KaiGai Kohei<kaigai@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.2070609@ak.jp.nec.com
http://archives.postgresql.org/message-id/A7739F610FB0BD89E310D85E@[172.26.14.62]

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

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: Re: restructuring "alter table" privilege checks
Следующее
От: Jaime Casanova
Дата:
Сообщение: Re: further explain changes