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
Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column |
Список | 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 по дате отправления: