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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marko Kreen <markokr(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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:28:32
Message-ID: 499075D0.9010303@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
>> 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.
>>

No, they have upgraded along the way. pg_dump carefully preserves the
with/without oids property of the tables it is dumping. And rightly so.
This has nothing to do with default_without_oids.

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

I have clients I have not yet managed to ween off oids, because they
have legacy apps, sometimes third party apps, that rely on them. I don't
want to make it any harder to get them over the hurdle.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2009-02-09 18:33:49 Re: new GUC var: autovacuum_process_all_tables
Previous Message Tom Lane 2009-02-09 18:09:16 Re: renaming "storage parameters"