Re: @@IDENTITY (Was: Access - ODBC - serial problem) - Mailing list pgsql-odbc

From scott.marlowe
Subject Re: @@IDENTITY (Was: Access - ODBC - serial problem)
Date
Msg-id Pine.LNX.4.33.0404121042530.14195-100000@css120.ihs.com
Whole thread Raw
In response to Re: @@IDENTITY (Was: Access - ODBC - serial problem)  ("Ed Brown" <ebrown@arcompanies.net>)
Responses Re: @@IDENTITY (Was: Access - ODBC - serial problem)
List pgsql-odbc
On Sat, 10 Apr 2004, Ed Brown wrote:

> I agree with the strangeness of Microsoft's name, but the capability is
> useful. What I do in a case like this is use the transaction capability.  If
> you do
>
> Begin transaction;
>     <Do the insert>;
>     Select max(oid_column_name) from table;
> Commit work;
>
> You are guaranteed to get the correct ID back in any system that supports
> transactions. Because all "real" databases support caching, it's
> computationally inexpensive, unless you have a trigger that will insert
> another record behind your back.

In Postgresql, this is NOT I/O inexpensive, but results in a seq scan of
the whole table to find the max value.

select oid_column_name from table order by oid_column_name desc limit 1

is computationally and I/O inexpensive if the table has an index on that
field.

However, I think you have to be in serializable transaction mode for that
code to be gauranteed not to get the wrong data.  But I'm not certain on
that one.


pgsql-odbc by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: fixes for psqlodbc-07.03.200, patch
Next
From: Tom Lane
Date:
Subject: Re: @@IDENTITY (Was: Access - ODBC - serial problem)