From: | Marko Kreen <markokr(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS |
Date: | 2009-02-09 12:47:21 |
Message-ID: | e51f66da0902090447m6ed55817re93fe2102daa8dc9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/9/09, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> David Fetter wrote:
> > On Sun, Feb 08, 2009 at 11:51:22AM -0500, Tom Lane wrote:
> > > Now, if you want to argue that we should get rid of SET WITHOUT OIDS
> > > altogether,
> >
> > +1 for removing it altogether. Row OIDs are and ugly wart :P
>
> That might be true but I know of apps that use them. Having the ability to
> migrate those slowly by using SET WITHOUT OIDS is a Good Thing (tm).
+1 for removal.
Also, whether the removal happens or not, I would suggest a setting that
makes Postgres accept, but ignore default_with_oids / WITH OIDS settings.
The problem is how to migrate apps that definitely do not use oids,
in a situation where you have hundred of databases.
Scanning all dbs and doing ALTER table would be option, if it would
work 100% and would not touch data. Otherwise is cannot be used.
Trying to manually manipulate dump files which are filled with
"SET default_with_oids" each time database is dumped/reloaded is also
not an option.
Currently the only sane path seems to patch Postgres to ignore the
settings, but that does not seem very user-friendly approach...
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | David Lee Lambert | 2009-02-09 12:48:22 | Re: UUIDs using e2fs library on Linux in 8.4 |
Previous Message | Zeugswetter Andreas OSB sIT | 2009-02-09 10:32:13 | RE: [HACKERS] 64 bit PostgreSQL 8.3.6 build on AIX 5300-09-02-0849 with IBM XL C/C++ 10.1.0.1 - initdb fails (could not dump unrecognized node type: 650) |