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

Re: Last inserted id

From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
To: "'pgsql-odbc(at)postgresql(dot)org'" <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: Last inserted id
Date: 2001-11-12 15:50:29
Message-ID: AA30E7BCCA5C1D4E88A231900F8325C00C7A@dogbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: pgsql-odbc

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us] 
> Sent: 12 November 2001 15:30
> To: Dhorwitz(at)ched(dot)uct(dot)ac(dot)za
> Cc: 'pgsql-odbc(at)postgresql(dot)org'
> Subject: Re: [ODBC] Last inserted id 
> 
> 
> David Horwitz <Dhorwitz(at)ched(dot)uct(dot)ac(dot)za> writes:
> > Actually the issue is b) is multi-user safe
> > *if*  you have an exclusive lock on the table. If you don't it is 
> > quite possible for a user to insert an other record between your 
> > insertion and the
> > currval() call
> 
> False.  Option B is multi-user safe, period.  The reason is 
> that currval returns the value last obtained by nextval *in 
> your own session*, independently of what anyone else has done 
> meanwhile.
> 
> I tend to prefer option A (select nextval and insert) myself, 
> just because it seems more intuitive.  But if that's not 
> convenient for some reason, option B works fine too.

Ahh, now I see where the (== my) confusion has occurred. Option B) being:

- do insert
- select current val.

Whereas I originally was arguing against my interpretation of the question
which was:

- Select current val
- Do insert
- Select setval('seq', current_val + 1)

Which isn't safe. 

Oh well.
My bad. 

Regards, Dave.

pgsql-odbc by date

Next:From: Bruce MomjianDate: 2001-11-12 19:23:23
Subject: Re: [ODBC] MD5 support for ODBC
Previous:From: Tom LaneDate: 2001-11-12 15:29:52
Subject: Re: Last inserted id

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