Re: OID wraparound (was Re: pg_depend) - Mailing list pgsql-hackers

Also, without OID's, how do you fix EXACT duplicate records that happen 
by accident? 

LER


>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 7/18/01, 3:46:30 PM, Rod Taylor <rbt@barchord.com> wrote regarding Re: 
OID wraparound (was Re: [HACKERS] pg_depend) :


> If OIDs are dropped a mechanism for retrieving the primary key of the
> last insert would be greatly appreciated.  Heck, it would be useful
> now (rather than returning OID).

> I much prefer retrieving the sequence number after the insert than
> before insert where the insert uses it.  Especially when trigger
> muckary is involved.

> --
> Rod Taylor

> Your eyes are weary from staring at the CRT. You feel sleepy. Notice
> how restful it is to watch the cursor blink. Close your eyes. The
> opinions stated above are yours. You cannot imagine why you ever felt
> otherwise.

> ----- Original Message -----
> From: "Tom Lane" <tgl@sss.pgh.pa.us>
> To: "Lamar Owen" <lamar.owen@wgcr.org>
> Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>; "PostgreSQL-development"
> <pgsql-hackers@postgresql.org>
> Sent: Wednesday, July 18, 2001 4:30 PM
> Subject: Re: OID wraparound (was Re: [HACKERS] pg_depend)


> > Lamar Owen <lamar.owen@wgcr.org> writes:
> > > On Wednesday 18 July 2001 16:06, Tom Lane wrote:
> > >> It remains to be debated exactly how users should control the
> choice for
> > >> user tables, and which choice ought to be the default.  I don't
> have a
> > >> strong opinion about that either way, and am prepared to hear
> > >> suggestions.
> >
> > > SET OIDGEN boolean for database-wide default policy.
> > > CREATE TABLE WITH OIDS for individual tables?  CREATE TABLE
> WITHOUT OIDS?
> >
> > Something along that line, probably.
> >
> > > ?? Is this sort of thing addressed by any SQL standard (Thomas?)?
> >
> > OIDs aren't standard, so the standards are hardly likely to help us
> > decide how they should work.
> >
> > I think the really critical choice here is how much backwards
> > compatibility we want to keep.  The most backwards-compatible way,
> > obviously, is OIDs on by default and things work exactly as they
> > do now.  But if we were willing to bend things a little then some
> > interesting possibilities open up.  One thing I've been wondering
> > about is whether an explicit WITH OIDS spec ought to cause automatic
> > creation of a unique index on OID for that table.  ISTM that any
> > application that wants OIDs at all would want such an index...
> >
> > regards, tom lane
> >
> > ---------------------------(end of
> broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to
> majordomo@postgresql.org
> >


> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly