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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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.

Browse pgsql-odbc by date

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