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 | 4B67904B.90505@ak.jp.nec.com обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-hackers |
(2010/02/02 11:31), Robert Haas wrote: > 2010/2/1 KaiGai Kohei<kaigai@ak.jp.nec.com>: >> (2010/02/02 11:09), Tom Lane wrote: >>> KaiGai Kohei<kaigai@ak.jp.nec.com> writes: >>>> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() code, >>>> not only ATPrepAlterColumnType(), according to what I mentioned above. >>> >>> What exactly do you claim is wrong with the ADD COLUMN case? >> >> ADD COLUMN case works correctly, but it takes unnecessary loops, >> because the find_all_inheritors() didn't provide the value to be >> set on the new pg_attribute.attinhcount. >> >> I'm saying it can be rewritten in more graceful manner using the >> new expected_parents argument. > > The subject line of this thread is getting less and less appropriate > to the content thereof. > > I am not in favor of doing anything for 9.0 that is not a bug fix. Are you talking about ATPrepAddColumn() only? Or both of ATPrepAddColumn() and ATPrepAlterColumnType()? My motivation to clean up ATPrepAddColumn() is less than the bugfix. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: