Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column
Дата
Msg-id 14029.1483571146@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Ответы Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> Right. But I think it's better to use attribute id, in case the code
> raising this error changes for any reason in future.

I agree.  The parent's "tdhasoid" flag is definitely based on the
existence of an ObjectIdAttributeNumber system column, not on whether the
column's name is "oid".  So doing a lookup by name to find the matching
child column is just weird, and cannot possibly lead to anything good.

> The code updating attinhcount and then updating the catalogs is same
> for user defined attributes and OID. Should we separate it out into a
> function and use that function instead of duplicating the code?

Didn't really seem worth the trouble ... maybe if it gets any longer
it'd be appropriate to do that.

> Your test uses tablenames starting with "_". I have not seen that
> style in the testcases. Is it intentional?

Yeah, I did not like that either.

Pushed with those corrections and some further fooling with the test case.
        regards, tom lane



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] Odd behavior with PG_TRY
Следующее
От: "Lewis, Ian \(Microstar Laboratories\)"
Дата:
Сообщение: Re: [HACKERS] Cluster wide option to control symbol case folding