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 or flat)
Thread:
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
advantage
> 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
it.
> 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.

Merlin

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-2014 The PostgreSQL Global Development Group