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

On 2/9/09, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Feb 9, 2009, at 7:47 AM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
> > 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.
> >
>
> Why? What benefit do we get out of denying users this option?

Why should we continue to support historical special case? It is not
a feature that adds anything to user experience with Postgres.

Anyway, that was my vote only. If there are developers interested
in supporting oids feel free to do so.

But now that I learned that ALTER TABLE WITHOUT OIDS either causes bugs
or requires table rewrite, it turned from minor annoyance to big annoyance.
So I'd like have a reasonable path for getting rid of them, which we don't
have currently. Removing them completely is simplest path, but adding
extra features to support it is another.

If we are talking about adding a feature, then I like retargeting
pg_dump --oids from data-only flag to apply to both data and schema.
Yes, this is incompatible change, but the change affects feature we
are discouraging anyway.

If this does not work, then we need another postgresql.conf option.

> > 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.
> >
>
> That might be true in your environment, but is certainly not true in
> general. We have many DDL commands that require full-table rewrites, and
> they are FAR from useless.

Compared to not having the DDL commands or having DDL commands that
do not rewrite the tables? ;)

--
marko