Re: Killing OIDs

From: Adrian Klaver <aklaver(at)comcast(dot)net>
To: jd(at)commandprompt(dot)com
Cc: pgsql-general(at)postgresql(dot)org, Steve Crawford <scrawford(at)pinpointresearch(dot)com>
Subject: Re: Killing OIDs
Date: 2009-02-11 18:01:21
Message-ID: 1468717142.3894651234375281711.JavaMail.root@sz0030a.emeryville.ca.mail.comcast.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

----- "Joshua D. Drake" <jd(at)commandprompt(dot)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
aklaver(at)comcast(dot)net

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2009-02-11 18:01:32 Re: Killing OIDs
Previous Message rhubbell 2009-02-11 18:00:05 postmaster LISTENing on UDP port 32938