Re: ALTER TABLE .. SET WITH / WITHOUT OIDS
От | Tom Lane |
---|---|
Тема | Re: ALTER TABLE .. SET WITH / WITHOUT OIDS |
Дата | |
Msg-id | 4916.1041548918@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | ALTER TABLE .. SET WITH / WITHOUT OIDS (Rod Taylor <rbt@rbt.ca>) |
Ответы |
Re: ALTER TABLE .. SET WITH / WITHOUT OIDS
Re: ALTER TABLE .. SET WITH / WITHOUT OIDS |
Список | pgsql-patches |
Rod Taylor <rbt@rbt.ca> writes: > Works somewhat like adding / dropping a column with the default of 0. After looking at this patch I'm inclined to reject it. The doc patch claims Adds or removes the <literal>OID</literal> column from a table. When enabling (setting with) OIDs in a table, the currently existing tuples are not immediately numbered. but the actual behavior is that the existing tuples are not numbered and *never can become numbered* --- only freshly-inserted rows will acquire OIDs. That puts a severe, probably fatal, limit on the usefulness of SET WITH OIDS. I can see some value in the SET WITHOUT OIDS half of the patch, as this gives a way of reclaiming space in a table that was unthinkingly created with OIDs. But I'm not sure we should expend the code space to provide just a one-way transformation. Or we could modify heap_update to assign an OID if it reads a zero OID from the old tuple in a relation that is marked as having OIDs. Not sure whether I like that behavior either, but at least it would provide a mechanism for causing the old rows to acquire OIDs. Comments? regards, tom lane
В списке pgsql-patches по дате отправления: