-----BEGIN PGP SIGNED MESSAGE-----
> From: Bruce Momjian <[EMAIL PROTECTED]>
> Date: Thu, 3 May 2001 13:29:55 -0400 (EDT)
> > insert into tablename(name) values('sample') returning oid
> > as the string would cause the returning value of the executeUpdate()
> > method to be the oid of inserted row (if successful) instead of the
> > count of updated rows.
> So you really want the OID from the update? We want to add RETURNING to
> the standard SQL capabilities of the backend.
Well... I want the oid from the update, but also the ability to use
Callable Statement to get the primary key as well.
The issue is the ability to find the generated index for the row
easilly with jdbc, without having to figure out if I'm using the
org.postgresql.Statement class. (Which with some pool managers, isn't
directly available.) I can use the OID to find the row just inserted,
and then lookup the generated index. If the callable statement could
return a value, then it's easy. But the class isn't really
implemented for that in the current postgresql jdbc driver. I figure
that until RETURNING is added to the backend, and callable statement
works, this would be an 'ok' workaround. Not a great workaround,
since I don't like 'overloading' a return value, especially in Java.
However, _if_ RETURNING is going to be in the standard SQL for the
next release, _and_ there are plans to update the jdbc driver to take
advantage of that in the callable statement, as well, then it makes
more sense _not_ to add my patch that implements the 'overloading' of
the return value in the jdbc driver.
I guess the issue is the ability to return the primary key from an
inserted row, for cases that it's auto-generated, such as using the
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Public key at http://www.keyserver.net
-----END PGP SIGNATURE-----
Ned Wolpert <[EMAIL PROTECTED]>
D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly