| From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
|---|---|
| To: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
| Cc: | pgsql-jdbc(at)postgresql(dot)org |
| Subject: | Re: getUdateCount() vs. RETURNING clause |
| Date: | 2009-11-25 13:42:27 |
| Message-ID: | 4B0D3443.7050902@opencloud.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
Oliver Jowett wrote:
> You never call getMoreResults(), so you are only looking at a single
> result, which is either a resultset or an update count, never both.
Also, looking at the code a bit more, RETURNING is a bit of a special
case. Normally, if you have a command that returns a resultset, the
command status is ignored (you generally don't care about the command
status of, for example, a SELECT). Presumably that's happening here too.
(But the advice regarding getMoreResults() is generally applicable, e.g.
if you have a multiple-statement query).
You may have more success using something like this:
> PreparedStatement pstmt = con.prepareStatement("UPDATE something with no RETURNING clause", new String[] { "some_column" });
> int updateCount = pstmt.executeUpdate();
> ResultSet results = pstmt.getGeneratedKeys();
The driver glues on an appropriate RETURNING clause and arranges for the
resulting resultset to appear via getGeneratedKeys(); the update count
should still appear as expected.
(I haven't actually tried this. caveat emptor)
-O
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Kellerer | 2009-11-25 14:03:43 | Re: getUdateCount() vs. RETURNING clause |
| Previous Message | Oliver Jowett | 2009-11-25 13:14:24 | Re: getUdateCount() vs. RETURNING clause |