From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rod Taylor <rbt(at)rbt(dot)ca> |
Cc: | PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: ALTER TABLE .. SET WITH / WITHOUT OIDS |
Date: | 2003-01-02 23:08:38 |
Message-ID: | 4916.1041548918@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Rod Taylor <rbt(at)rbt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-01-02 23:16:07 | Re: pg_dump.options.diff |
Previous Message | Nic Ferrier | 2003-01-02 22:57:54 | Re: [PATCHES] Fwd: Patch for streaming resultsets |