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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, David Fetter <david(at)fetter(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS
Date: 2009-02-09 18:02:35
Message-ID: 18284.1234202555@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marko Kreen <markokr(at)gmail(dot)com> writes:
> 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.

That's a pretty overstated claim. It's exactly the same tool as before,
it's just slower.

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

Indeed. If they have not bothered to remove oids from their tables up
to now, what are the odds that they're going to bother in the future?

IMHO, the only way they'd care is if we try to force them to care
(ie by removing oids as a user option), which I'm against. So I see
no flag day here. They'll still have oids and they still won't care.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-02-09 18:09:16 Re: renaming "storage parameters"
Previous Message Robert Haas 2009-02-09 17:55:44 Re: renaming "storage parameters"