Re: introduce "default_use_oids" - Mailing list pgsql-patches

From Peter Eisentraut
Subject Re: introduce "default_use_oids"
Date
Msg-id Pine.LNX.4.44.0312021024540.9834-100000@peter.localdomain
Whole thread Raw
In response to Re: introduce "default_use_oids"  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: introduce "default_use_oids"  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: introduce "default_use_oids"  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: introduce "default_use_oids"  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
Christopher Kings-Lynne writes:

> > Significant effort has been invested to make pg_dump output portable, and
> > I've not had any problems with it last time I tried it.  Please explain
> > why you think it's "totally" non-portable.
>
> Functions, indexes, operators, types, aggregates, users, groups,
> databases, inheritance, clustering, col stats, col storage, ...
>
> What IS compatible?  Very basic table definitions?

If I want to develop a portable application or I want to port an
application, then I am of course only going to use portable constructs,
that is, tables and views, and possibly sequences.  I'm not talking theory
here -- I've actually done it and made several changes to pg_dump along
the way to make the output portable.  This is an actual feature that is
being destroyed.

I'm sure there are other ways to phase out OIDs in dumps.  For example, we
could set the default mode at the top (easily deleted, much safer than
running a global search and replace) and then add WITH/WITHOUT OIDS only
to those tables that deviate from the default.

--
Peter Eisentraut   peter_e@gmx.net


pgsql-patches by date:

Previous
From: Manfred Koizar
Date:
Subject: Re: [HACKERS] Index creation takes for ever
Next
From: Bruce Momjian
Date:
Subject: Re: introduce "default_use_oids"