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

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

In response to

Responses

Browse pgsql-hackers by date

  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