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  (Rod Taylor <rbt@rbt.ca>)
Re: ALTER TABLE .. SET WITH / WITHOUT OIDS  (Neil Conway <neilc@samurai.com>)
Список 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 по дате отправления:

Предыдущее
От: Nic Ferrier
Дата:
Сообщение: Re: Fwd: Patch for streaming resultsets
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] pg_dump.options.diff