Re: SELECT @@IDENTITY

From: Steve Lane <slane(at)moyergroup(dot)com>
To: <pgsql-general(at)postgresql(dot)org>
Subject: Re: SELECT @@IDENTITY
Date: 2003-06-23 21:23:18
Message-ID: BB1CD9F6.327B7%slane@moyergroup.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 6/23/03 3:32 PM, "Robert J. Sanford, Jr." <rsanford(at)trefs(dot)com> wrote:

>> From the user docs I read...
>
> currval(text)
> "Return the value most recently obtained by nextval
> for this sequence in the current session. (An error
> is reported if nextval has never been called for
> this sequence in this session.) Notice that because
> this is returning a session-local value, it gives a
> predictable answer even if other sessions are
> executing nextval meanwhile."
>
> While that does mostly what I want it doesn't do it completely. With this I
> am forced to specify the name of the sequence that I want the currval for.
> What I really, really want is to not have to worry about it. The reason
> being that I have a persistence framework that I want to port from SQL
> Server to PostgreSQL. The framework base class object knows it is working on
> an object but doesn't really know what object it is. Under SQL Server it
> does an insert using a static method call and then sets the internal unique
> key based on the call to SELECT @@IDENTITY. It's simple and nice. Pretty
> much everything else works with minimal mods. With this I'll have to
> actually do some real work to make the conversion.

Hmm, point taken. Clearly you'd need some work in your base class. I suppose
something minimal could be that you adopt a naming convention for your
sequences such that their names can be mechanically derived from the class
names in your persistence framework (assuming an at most one-to-one
correspondence between sequences and your classes). You'd have to do a bit
more work setting up your schema since you probably couldn't use the
postgres default name for any sequence, but this might be a manageable path.

--sgl

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Dann Corbit 2003-06-23 21:38:28 NIST test defects
Previous Message Tom Lane 2003-06-23 21:17:36 Re: Eliminating start error message: "unary operator