----- "Joshua D. Drake" <j...@commandprompt.com> wrote:
> On Wed, 2009-02-11 at 09:41 -0800, Steve Crawford wrote:
> > I'm about to deal with an upgrade of a server running 7.4. I have
> > checked with the developers and they are not using OIDs so I'd like
> to
> > remove them so they aren't carried forward to 8.3.
> >
> > My plan is to do the OID removal on 7.4. I can get a script with:
> > SELECT
> > 'ALTER TABLE ' || relname || ' SET WITHOUT OIDS;'
> > FROM
> > pg_class
> > WHERE
> > relkind='r' and
> > relowner != 1 and
> > relhasoids;
> >
> > Before I pull the trigger, I figured I'd post and find out if anyone
>
> > sees any feet in the way.
>
> That won't drop the OID columns.
>
> Joshua D. Drake
>
>
Now I am confused. From the docs I get:
SET WITHOUT OIDS
This form removes the oid column from the table. Removing OIDs from a table
does not occur immediately. The space that the OID uses will be reclaimed when
the row is updated. Without updating the row, both the space and the value of
the OID are kept indefinitely. This is semantically similar to the DROP COLUMN
process.
I remember from past posts, that to get rid of the OIDS you can do a 'fake'
update on the whole table to reclaim the space. The case the OP is dealing with
he does not want the OID setting to propagate via the dump/restore cycle. The
above statement would do that or am I mistaken?
Thanks,
Adrian Klaver
akla...@comcast.net
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
