Re: OID wraparound (was Re: pg_depend)

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(at)barchord(dot)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(at)sss(dot)pgh(dot)pa(dot)us>
> To: "Lamar Owen" <lamar(dot)owen(at)wgcr(dot)org>
> Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>; "PostgreSQL-development"
> <pgsql-hackers(at)postgresql(dot)org>
> Sent: Wednesday, July 18, 2001 4:30 PM
> Subject: Re: OID wraparound (was Re: [HACKERS] pg_depend)

> > Lamar Owen <lamar(dot)owen(at)wgcr(dot)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(at)postgresql(dot)org
> >

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