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 | 4B4173F9.2030604@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO
on inherited columns
|
Список | pgsql-hackers |
(2010/01/04 13:18), Tom Lane wrote: > Robert Haas<robertmhaas@gmail.com> writes: >> 2010/1/3 KaiGai Kohei<kaigai@ak.jp.nec.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? Yes, > 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. find_all_inheritors() returns a clean list which does not contain duplicated OID of the inherited relation, so it seems to me we need to change the function prototype but it affects other parts, or to add a new function which also returns number of duplications, not only OIDs. Or, we can call find_inheritance_children() in renameatt() as if find_all_inheritors() doing except for list_concat_unique_oid(). What is the most preferable? I don't have any preference in the way to fix the problem. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: