From: | Rod Taylor <rbt(at)rbt(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: ALTER TABLE .. SET WITH / WITHOUT OIDS |
Date: | 2003-01-02 23:27:10 |
Message-ID: | 1041550029.88730.14.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
> 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
This is the part I'm after -- for those older tables created before OIDs
could be removed. Editing dump files won't work. I can just muck with
the system tables, but others may not be able to (for whatever reason).
> 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.
Thought about that, but didn't like it as it makes oid more special than
it already is. Adding a default to a column works basically the same
way.
Another, and my original option, was to touch all tuples to assign new
OIDS at addition time -- but that requires a lot of resources.
--
Rod Taylor <rbt(at)rbt(dot)ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2003-01-03 01:10:03 | targetlist functions proposals (was SETOF input parameters) |
Previous Message | Tom Lane | 2003-01-02 23:16:07 | Re: pg_dump.options.diff |