From: | Matt Miller <mattm(at)epx(dot)com> |
---|---|
To: | PostgreSQL - GENERAL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: "returning" in postgresql request |
Date: | 2005-06-09 16:02:56 |
Message-ID: | 1118332976.3596.16.camel@dbamm01-linux |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> > deploy an Application with Oracle Database to a solution with postgresql.
> > ...
> > UPDATE xdb_ancestors_lock SET nb_lock=nb_lock+1 WHERE doc_id=? AND >
> > ele_id=? returning nb_lock INTO nb;
> Looks like you really want:
>
> UPDATE xdb_ancestors_lock SET nb_lock=nextval('nb_lock_sequence') WHERE
> doc_id=? AND ele_id=?;
> SELECT currval('nb_lock_sequence');
We have similar code in our Oracle-but-hopefully-soon-to-be-PostgreSQL
apps. However, in our case the sequence generator is used in an insert
trigger to populate a column. So, although I could use "currval" after
the insert to see what the trigger used, that would force the currval-
invoking code to know the internals of the insert trigger. This is a
bit of an abstraction violation, I think.
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-06-09 16:05:02 | Re: database auto-commit |
Previous Message | Tom Lane | 2005-06-09 15:19:36 | Re: Postgre "idle" process using 100% CPU |