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

On 2/9/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Yes. I agree with the patch. And I'm all for robustness.

> 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.

No. I'm not concerned with ALTER command, I'm concerned about reloading
dumps from older versions. So my, uh, new argument is - starting with 8.4,
it is very hard to get rid of oids on user tables because all the tools
work against user.

So either: the 8.4 will be a "flag day" and all users need to clean up
their database on 8.3, or we give some option for them to lessen the pain.

Considering that default_with_oids went false in 8.1 (?), affected are
users who are reusing their dumps or postgresql.conf from 8.0 and below.

Maybe there are not many of such users (?) so flag day approach it ok.

--
marko