Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns |
| Дата | |
| Msg-id | 22237.1265077921@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns (KaiGai Kohei <kaigai@ak.jp.nec.com>) |
| Список | pgsql-hackers |
KaiGai Kohei <kaigai@ak.jp.nec.com> writes:
> (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.
I tend to think that if it ain't broke don't fix it; the odds of
actually breaking it are too high. I don't really find the new coding
more graceful, anyway ...
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера