From: | Marko Kreen <markokr(at)gmail(dot)com> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, 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 13:19:55 |
Message-ID: | e51f66da0902090519g37fd8a1fl27495db764e699e7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/9/09, Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:
> On Mon, Feb 09, 2009 at 02:47:21PM +0200, Marko Kreen wrote:
> > > 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.
>
> Err, you mean a setting that makes Postgres throw an error on the use
> of WITH OIDS. Just silently ignoring the option is a fantastic way to
> break applications silently.
For me, ignoring is easier... But yeah, error would be better,
if it does not affect reloading the dump.
> Making pg_dump not output the WITH OIDS option on tables may be an
> easier option.
I don't like it - it would require more work from users, but does
not seem to be any way safer. You usually do the check if db works
on restore time, not dump time...
From clarity standpoint, options that turns both default_with_oids
and WITH OIDS to errors seems the best.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2009-02-09 13:21:25 | Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS |
Previous Message | Heikki Linnakangas | 2009-02-09 13:05:41 | Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS |