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