> > 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.
