Thread: JDBC-94: "Multiple resultsets were returned by query" in query end with "; "

Hi, 

I'm using postgresql-jdbc94 and have found that, 

string in executeQuery() end with "; " (the last character is a space) 

is considered as multiple queries and return with 

"Multiple resultsets were returned by query" error.

I think it is not a bug, but is there any related change in jdbc94. I could not reproduce in jdbc93.

Best regards,

Bocap

On 29 September 2015 at 21:56, Dang Minh Huong <kakalot49@gmail.com> wrote:
> Hi,
>
> I'm using postgresql-jdbc94 and have found that,
> string in executeQuery() end with "; " (the last character is a space)
> is considered as multiple queries and return with
> "Multiple resultsets were returned by query" error.
> I think it is not a bug, but is there any related change in jdbc94. I could
> not reproduce in jdbc93.

This is a follow-up from a Stack Overflow post, right? I'm pretty sure
I saw this but I can't find  the post now. If I'm remembering
correctly, got a link so I can cross-reference?

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

I wonder why pgjdbc would want to silently ignore that user error?
Is "behavior of previous version" a sole justification?

I've drafted https://github.com/pgjdbc/pgjdbc/pull/386 to cover that.

Vladimir

I agree with Christopher. After upgrading to the latest JDBC driver our system started throwing these exceptions. It's not hard for us to fix (I can update our own framework code), but it seems unnecessary and is likely more difficult for others to address.

Here's a simplified example of SQL-generatation code that runs afoul of this change: in our system, a logical insert at one layer may map to multiple database inserts (e.g., to a primary database table plus one or more property tables). The code generating the insert SQL terminates each INSERT with ";\n", for convenience and human readability. As a result, the final INSERT can end with a dangling "\n" that 1202 now rejects. Of course, we could duplicate a subsequent check and/or special case the last INSERT to remove the "\n", but the current code is cleaner.

Adam

On 10/7/2015 5:42 AM, Christopher BROWN wrote:

Hello,

Developers that use the driver via a framework (open-source, in-house) might not be in a position to change SQL, compared with developers that are able to modify hand-written SQL, so it's probably best to tolerate it by discarding any trailing semi-colon (with or without any trailing whitespace) in the parser.

I've also encountered coding practices (coding-style "standards") where semi-colons are expected (some people just love terminating all statements, not just Java, with semi-colons, even when it's not strictly necessary (e.g.: JavaScript).

So, my preference would be to maintain backwards-compatibility for others, even if I don't have such an issue myself.

--

Christopher

On 7 October 2015 at 14:34, Dave Cramer <pg@fastcrypt.com> wrote:

This is a very good question, but lots of people cut and paste SQL into code ... sometimes the ; gets in there.

Behaviour of previous version is important, but in this case It may not be justified.

Anyone else have an opinion ?

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 7 October 2015 at 08:30, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:

I wonder why pgjdbc would want to silently ignore that user error?
Is "behavior of previous version" a sole justification?

I've drafted https://github.com/pgjdbc/pgjdbc/pull/386 to cover that.

Vladimir