Re: OIDs as keys

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, daniel alvarez <d-alvarez(at)gmx(dot)de>, Richard Huxton <dev(at)archonet(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: OIDs as keys
Date: 2003-03-05 13:54:58
Message-ID: 1046872498.10615.17.camel@tokyo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, 2003-02-27 at 02:30, Tom Lane wrote:
> It's moving in the wrong direction. We've been slowly eliminating
> unnecessary nonstandardisms in pg_dump output; this puts in a new one
> in a quite fundamental place. You could perhaps expect another DB
> to drop commands it didn't understand like SET SEARCH_PATH ... but if
> it drops all your CREATE TABLEs, you ain't got much dump left to load.

Rather than specifying the use of OIDs by WITH OIDS clauses for each
CREATE TABLE in a dump, couldn't we do it by adding a SET command that
toggles the 'use_oids' GUC option prior to every CREATE TABLE? That way,
a user concerned with portability could fairly easily strip out (or just
ignore) the SET commands.

Cheers,

Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Rod Taylor 2003-03-05 14:05:56 Re: OIDs as keys
Previous Message Greg Stark 2003-03-05 12:42:18 Re: Planner matching constants across tables in a join