Skip site navigation (1) Skip section navigation (2)

Re: [NOVICE] Last ID Problem

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Greg Stark" <gsstark(at)mit(dot)edu>
Cc: <pgsql-hackers(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [NOVICE] Last ID Problem
Date: 2005-02-02 17:14:10
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3412A75FF@Herge.rcsinc.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> "INSERT/UPDATE ... RETURNING" isn't something a driver can take
> of.
> It would require it to modify your statements which it can't do
safely. So
> your application would have such non-portable SQL code written into
> Switch
> databases and your application code needs to be ported.

I really don't think it matters.  Currently, in PostgreSQL, there is
only 'one true way' to have a real unique identifier for any given tuple
that is persistent across queries and this is a sequence.  Since
sequences are basically managed by the app, your driver (I'm assuming)
can't reliably use them.

This is kind of similar to the issues being talked about wrt user locks.
Because the lack of a true persistent tuple identifier, they require
some data to be passed to them from the app (not really a big deal for
them, however).

From the point of view of your driver, the real solution is to bump oid
to 64 bits and un-deprecate it.


pgsql-hackers by date

Next:From: Dann CorbitDate: 2005-02-02 17:21:09
Subject: Enhancement suggestion
Previous:From: Bruce MomjianDate: 2005-02-02 17:14:00
Subject: Re: 7.3.8 under FC3 takes excessive semaphores?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group