Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS

Marko Kreen <markokr(at)gmail(dot)com> writes:
> On 2/9/09, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> Do you still need the oids? If not, run ALTER TABLE WITHOUT OIDS before
>> upgrading to 8.4, while it's still fast. If yes, you couldn't use the option
>> to remove them at pg_dump anyway because you still need them after the
>> upgrade.

> Indeed. I must apologize. I seems I read too fast and got the impression
> the bug applies also to older versions of Postgres. If this is not
> the case and ALTER still works fine on older versions, most of my comments
> do not apply, because indeed, we can clean it up on 8.3.

I think actually we are in violent agreement ;-). The argument for
getting rid of userland OIDs, as far as I can see, is to eliminate
future development effort and risk of bugs associated with them.
Now if OIDs are staying in system tables ... which they are, for the
foreseeable future ... then the only real cost or risk associated with
userland OIDs is driven precisely by ALTER SET WITHOUT OIDS. Because
that creates a situation with a table that used to have OIDs and no
longer does, except there are still vestiges of its having OIDs, ie rows
in the table that contain an OID. So the patch I'm proposing attacks
that problem directly by making sure there is no intermediate status.
Either a table has OIDS (and so do all its rows) or not (and none of
its rows do either). I think this pretty much eliminates the risk of
induced bugs, and it does it without taking away functionality that
applications might depend on.

Unless you want to argue that "SET WITHOUT OIDS is fast" is a property
that apps are depending on, but that seems like a bit of a stretch.

regards, tom lane