I use XID's regularly now for historical purposes (delayed reversion
of entire operations -- handled by an interface of course where
appropriate) but OID's I could certainly live without. However, PHP
currently returns the OID in from pg_getlastoid() which I use to
select from the table the last PRIMARY KEY entry. Getting this key
before sometimes isn't an option (triggers handle them sometimes). If
I could have a pg_getlastprimarykey() function which returns a hash of
name / value pairs of the new key without using the OID it would be
ideal.
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
----- Original Message -----
From: "Peter Eisentraut" <peter_e@gmx.net>
To: "Rod Taylor" <rod.taylor@inquent.com>
Cc: <pgsql-general@postgresql.org>
Sent: Friday, March 02, 2001 11:31 AM
Subject: Re: [GENERAL] Re: Thought on OIDs
> Rod Taylor writes:
>
> > Someones bound to hit it in a year or 2 as Postgres is getting
pretty
> > good for large projects as well as the small, especially with
7.1's
> > speed enhancements. Hopefully 7.2 will create cycling OIDs and
XIDs.
> > Then less problems in 'unlimited' extendability.
>
> The easiest approach for OIDs will probably be making them optional
in the
> first place. For the vast majority of users, the OIDs are just
wasting
> space.
>
> The cycling XID idea is based on the assertion that eventually all
> transactions will be closed, at which time a record is either known
> committed or known dead so that the XID can be recycled. For OIDs,
this
> is not practical. And if you wanted OIDs that automatically fill in
the
> holes, that's probably not realistic.
>
> --
> Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
>
>
> ---------------------------(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
>