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

I've pushed the PR so the next version will not do this

Dave Cramer

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

On 7 October 2015 at 14:42, Adam Rauch <adam(at)labkey(dot)com> wrote:

> 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(at)fastcrypt(dot)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(dot)vladimir(at)gmail(dot)com>sitnikov(dot)vladimir(at)gmail(dot)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
>>>
>>
>>
>
>