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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
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:59:45
Message-ID: 19678.1234205985@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> 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.

Surely the major cost there is going to be fixing those apps; I think
focusing on whether SET WITHOUT OIDS is zero-cost is worrying about
entirely the wrong thing.

Also, if they are using the oids (and presumably relying on them to be
unique), the tables can't be as huge as all that --- they'd have to be
under a billion or so rows, else the 32-bit width of oids would have
forced a change a long time ago. So even a rewriting form of SET WITHOUT
OIDS doesn't seem all that painful. Compared to an app migration that's
still not happened after N years, I can't believe it's a problem.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John Lister 2009-02-09 19:20:40 Re: database corruption help
Previous Message Florian Weimer 2009-02-09 18:51:12 Re: renaming "storage parameters"