Обсуждение: Invoking a function within a batch statement
Hello,
I'm having trouble invoking a PostgreSQL function within a prepared batch statement, and I'm wondering if it's possible that I'm encountering a limitation in the JDBC driver.
--
For context, my application uses jDBI v2.63.1 with version 9.4-1204-jdbc42 of the Postgres driver. I've implemented a feature which requires insertion into certain tables using a custom PL/pgSQL function. In order to issue batches of these queries within a single transaction, I'd like to use jDBI's `@SqlBatch` annotation. However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.
The jDBI-annotated DAO method in question:
@SqlBatch(
transactional=true,
value="SELECT append_to_time_series(<
public void insertV2(
...
);
This results in a BatchUpdateException wrapping a PSQLException which indicates a root cause of an unexpected null result: https://gist.github.
This issue is being tracked in a jDBI issue on GitHub, which links to some relevant discussion that took place on the jDBI mailing list. Any insight from the JDBC community would be greatly appreciated.
Evan Meagher
I think you should be able to use {call proc(params)} form, see https://jdbc.postgresql.org/documentation/80/callproc.html
Best regards, Vitalii Tymchyshyn
Ср, 17 серп. 2016 10:24 користувач Evan Meagher <evan.meagher@gmail.com> пише:
Hello,I'm having trouble invoking a PostgreSQL function within a prepared batch statement, and I'm wondering if it's possible that I'm encountering a limitation in the JDBC driver.For context, my application uses jDBI v2.63.1 with version 9.4-1204-jdbc42 of the Postgres driver. I've implemented a feature which requires insertion into certain tables using a custom PL/pgSQL function. In order to issue batches of these queries within a single transaction, I'd like to use jDBI's `@SqlBatch` annotation. However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.The jDBI-annotated DAO method in question:@SqlBatch(transactional=true,value="SELECT append_to_time_series(<arguments_redacted>)")public void insertV2(...);This results in a BatchUpdateException wrapping a PSQLException which indicates a root cause of an unexpected null result: https://gist.github.com/evnm/17a370c6ead2a2dfeaab0285e067897aThis issue is being tracked in a jDBI issue on GitHub, which links to some relevant discussion that took place on the jDBI mailing list. Any insight from the JDBC community would be greatly appreciated.--Evan Meagher
On Wed, 2016-08-17 at 15:06 +0000, Vitalii Tymchyshyn wrote:
> I think you should be able to use {call proc(params)} form, see https
> ://jdbc.postgresql.org/documentation/80/callproc.html
> Best regards, Vitalii Tymchyshyn
>
Or see https://jdbc.postgresql.org/documentation/94/callproc.html
which is the latest doco.
Note that 1209 is the most recent driver.
HTH,
rob
Thanks for the replies. I was under the impression that the `{call ...}` syntax in JDBC only applied to stored procedures, so that's good to know regarding functions that return refcursors. However, as Example 6.2 on that page illustrates, one must use SELECT to invoke functions that return SETOF results.
In my use case, the function boils down to the invocation of an INSERT statement, so there is no result. And more generally, it seems to me that JDBC should support the batch SETOF-returning function use case. That is to say, JDBC probably shouldn't reject non-none results as it currently seems to be.
On Wed, Aug 17, 2016 at 8:16 AM, rob stone <floriparob@gmail.com> wrote:
On Wed, 2016-08-17 at 15:06 +0000, Vitalii Tymchyshyn wrote:
> I think you should be able to use {call proc(params)} form, see https
> ://jdbc.postgresql.org/documentation/80/callproc.html
> Best regards, Vitalii Tymchyshyn
>
Or see https://jdbc.postgresql.org/documentation/94/callproc.html
which is the latest doco.
Note that 1209 is the most recent driver.
HTH,
rob
Evan Meagher
I think you should be able to use {call proc(params)} form, see https://jdbc.postgresql.org/documentation/80/callproc.html
Best regards, Vitalii Tymchyshyn
Ср, 17 серп. 2016 10:24 користувач Evan Meagher <evan.meagher@gmail.com> пише:
Hello,I'm having trouble invoking a PostgreSQL function within a prepared batch statement, and I'm wondering if it's possible that I'm encountering a limitation in the JDBC driver.For context, my application uses jDBI v2.63.1 with version 9.4-1204-jdbc42 of the Postgres driver. I've implemented a feature which requires insertion into certain tables using a custom PL/pgSQL function. In order to issue batches of these queries within a single transaction, I'd like to use jDBI's `@SqlBatch` annotation. However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.The jDBI-annotated DAO method in question:@SqlBatch(transactional=true,value="SELECT append_to_time_series(<arguments_redacted>)")public void insertV2(...);This results in a BatchUpdateException wrapping a PSQLException which indicates a root cause of an unexpected null result: https://gist.github.com/evnm/17a370c6ead2a2dfeaab0285e067897aThis issue is being tracked in a jDBI issue on GitHub, which links to some relevant discussion that took place on the jDBI mailing list. Any insight from the JDBC community would be greatly appreciated.--Evan Meagher
On Wed, 2016-08-17 at 15:06 +0000, Vitalii Tymchyshyn wrote:
> I think you should be able to use {call proc(params)} form, see https
> ://jdbc.postgresql.org/documentation/80/callproc.html
> Best regards, Vitalii Tymchyshyn
>
Or see https://jdbc.postgresql.org/documentation/94/callproc.html
which is the latest doco.
Note that 1209 is the most recent driver.
HTH,
rob
Thanks for the replies. I was under the impression that the `{call ...}` syntax in JDBC only applied to stored procedures, so that's good to know regarding functions that return refcursors. However, as Example 6.2 on that page illustrates, one must use SELECT to invoke functions that return SETOF results.
In my use case, the function boils down to the invocation of an INSERT statement, so there is no result. And more generally, it seems to me that JDBC should support the batch SETOF-returning function use case. That is to say, JDBC probably shouldn't reject non-none results as it currently seems to be.
On Wed, Aug 17, 2016 at 8:16 AM, rob stone <floriparob@gmail.com> wrote:
On Wed, 2016-08-17 at 15:06 +0000, Vitalii Tymchyshyn wrote:
> I think you should be able to use {call proc(params)} form, see https
> ://jdbc.postgresql.org/documentation/80/callproc.html
> Best regards, Vitalii Tymchyshyn
>
Or see https://jdbc.postgresql.org/documentation/94/callproc.html
which is the latest doco.
Note that 1209 is the most recent driver.
HTH,
rob
Evan Meagher
Well we don't actually have stored procs so we do the next best thing.. Let us know how the call syntax works out for you
On 17 August 2016 at 11:55, Evan Meagher <evan.meagher@gmail.com> wrote:
Thanks for the replies. I was under the impression that the `{call ...}` syntax in JDBC only applied to stored procedures, so that's good to know regarding functions that return refcursors. However, as Example 6.2 on that page illustrates, one must use SELECT to invoke functions that return SETOF results.In my use case, the function boils down to the invocation of an INSERT statement, so there is no result. And more generally, it seems to me that JDBC should support the batch SETOF-returning function use case. That is to say, JDBC probably shouldn't reject non-none results as it currently seems to be.On Wed, Aug 17, 2016 at 8:16 AM, rob stone <floriparob@gmail.com> wrote:
On Wed, 2016-08-17 at 15:06 +0000, Vitalii Tymchyshyn wrote:
> I think you should be able to use {call proc(params)} form, see https
> ://jdbc.postgresql.org/documentation/80/callproc.html
> Best regards, Vitalii Tymchyshyn
>
Or see https://jdbc.postgresql.org/documentation/94/callproc.html
which is the latest doco.
Note that 1209 is the most recent driver.
HTH,
rob--Evan Meagher
Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.
Evan,
Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?
The idea is as follows:
1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS);
2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".
Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488#issuecomment-237908650 ), however historical behavior was just fail with "A result was returned when none was expected"
The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.
Vladimir
Well we don't actually have stored procs so we do the next best thing.. Let us know how the call syntax works out for you
On 17 August 2016 at 11:55, Evan Meagher <evan.meagher@gmail.com> wrote:
Thanks for the replies. I was under the impression that the `{call ...}` syntax in JDBC only applied to stored procedures, so that's good to know regarding functions that return refcursors. However, as Example 6.2 on that page illustrates, one must use SELECT to invoke functions that return SETOF results.In my use case, the function boils down to the invocation of an INSERT statement, so there is no result. And more generally, it seems to me that JDBC should support the batch SETOF-returning function use case. That is to say, JDBC probably shouldn't reject non-none results as it currently seems to be.On Wed, Aug 17, 2016 at 8:16 AM, rob stone <floriparob@gmail.com> wrote:
On Wed, 2016-08-17 at 15:06 +0000, Vitalii Tymchyshyn wrote:
> I think you should be able to use {call proc(params)} form, see https
> ://jdbc.postgresql.org/documentation/80/callproc.html
> Best regards, Vitalii Tymchyshyn
>
Or see https://jdbc.postgresql.org/documentation/94/callproc.html
which is the latest doco.
Note that 1209 is the most recent driver.
HTH,
rob--Evan Meagher
Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.
Evan,
Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?
The idea is as follows:
1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS);
2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".
Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488#issuecomment-237908650 ), however historical behavior was just fail with "A result was returned when none was expected"
The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.
Vladimir
> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'
> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?
That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.
I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!
On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS); 2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488# issuecomment-237908650 ), however historical behavior was just fail with "A result was returned when none was expected" The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.Vladimir
Evan Meagher
> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'
> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?
That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.
I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!
On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS); 2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488# issuecomment-237908650 ), however historical behavior was just fail with "A result was returned when none was expected" The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.Vladimir
Evan Meagher
Evan,
On 22 August 2016 at 23:37, Evan Meagher <evan.meagher@gmail.com> wrote:
> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'
Can you show us exactly what you did here the { should not be getting through to the backend.
> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!--On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS); 2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488#issuecomment- 237908650 ), however historical behavior was just fail with "A result was returned when none was expected" The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.VladimirEvan Meagher
Evan>Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'
My guess is CallableStatement was not used, thus no replacement of { ... } was made, thus backend did receive those curly braces.
My guess is CallableStatement was not used, thus no replacement of { ... } was made, thus backend did receive those curly braces.
I'm not sure if SqlObject can do con.prepareCall instead of con.prepareStatement
Evan>That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation
That sounds strange to me, and I don't think that kind of test is in pgjdbc's regression suite.
Evan, it would be great if you could provide a self-contained test case that fails with "pre 1210" version so we won't accidentally break that behavior.
Vladimir
Evan,
On 22 August 2016 at 23:37, Evan Meagher <evan.meagher@gmail.com> wrote:
> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'
Can you show us exactly what you did here the { should not be getting through to the backend.
> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!--On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS); 2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488#issuecomment- 237908650 ), however historical behavior was just fail with "A result was returned when none was expected" The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.VladimirEvan Meagher
Evan>Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'
My guess is CallableStatement was not used, thus no replacement of { ... } was made, thus backend did receive those curly braces.
My guess is CallableStatement was not used, thus no replacement of { ... } was made, thus backend did receive those curly braces.
I'm not sure if SqlObject can do con.prepareCall instead of con.prepareStatement
Evan>That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation
That sounds strange to me, and I don't think that kind of test is in pgjdbc's regression suite.
Evan, it would be great if you could provide a self-contained test case that fails with "pre 1210" version so we won't accidentally break that behavior.
Vladimir
Correct syntax is {call procedure(params)}. I think you forgot "call".
Пн, 22 серп. 2016 23:38 користувач Evan Meagher <evan.meagher@gmail.com> пише:
> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS);2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488#issuecomment-237908650 ), however historical behavior was just fail with "A result was returned when none was expected"The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.Vladimir--Evan Meagher
Sorry, I noticed that mistake after sending as well. The query statement I used included the `call` keyword, I just missed it when augmenting the simplified example code from my initial email.
I modified by original jDBI DAO method with the `{call ...}` syntax thusly:
@SqlBatch(
transactional=true,
value="{call append_to_time_series(...)}")
public void insert(...);
> Evan, it would be great if you could provide a self-contained test case that fails with "pre 1210" version so we won't accidentally break that behavior.
I will see if I can tickle this issue with an addition to jDBI's test suite. It already has a few test classes that target specific corners of Postgres/pgjdbc. I'll update this thread once I have something replicable.
On Tue, Aug 23, 2016 at 11:25 AM, Vitalii Tymchyshyn <vit@tym.im> wrote:
Correct syntax is {call procedure(params)}. I think you forgot "call".Пн, 22 серп. 2016 23:38 користувач Evan Meagher <evan.meagher@gmail.com> пише:> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS); 2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488# issuecomment-237908650 ), however historical behavior was just fail with "A result was returned when none was expected" The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.Vladimir--Evan Meagher
Evan Meagher
Correct syntax is {call procedure(params)}. I think you forgot "call".
Пн, 22 серп. 2016 23:38 користувач Evan Meagher <evan.meagher@gmail.com> пише:
> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS);2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488#issuecomment-237908650 ), however historical behavior was just fail with "A result was returned when none was expected"The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.Vladimir--Evan Meagher
Sorry, I noticed that mistake after sending as well. The query statement I used included the `call` keyword, I just missed it when augmenting the simplified example code from my initial email.
I modified by original jDBI DAO method with the `{call ...}` syntax thusly:
@SqlBatch(
transactional=true,
value="{call append_to_time_series(...)}")
public void insert(...);
> Evan, it would be great if you could provide a self-contained test case that fails with "pre 1210" version so we won't accidentally break that behavior.
I will see if I can tickle this issue with an addition to jDBI's test suite. It already has a few test classes that target specific corners of Postgres/pgjdbc. I'll update this thread once I have something replicable.
On Tue, Aug 23, 2016 at 11:25 AM, Vitalii Tymchyshyn <vit@tym.im> wrote:
Correct syntax is {call procedure(params)}. I think you forgot "call".Пн, 22 серп. 2016 23:38 користувач Evan Meagher <evan.meagher@gmail.com> пише:> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS); 2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488# issuecomment-237908650 ), however historical behavior was just fail with "A result was returned when none was expected" The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.Vladimir--Evan Meagher
Evan Meagher
I've created a branch which adds a test to jDBI's TestPreparedBatchGenerateKeysPostgres class which triggers the "A result was returned when none was expected" error: https://github.com/evnm/jdbi/commit/407b3770fab7e606a88be44a5eb0e8141b012e04
Here's the test output I'm seing locally: https://gist.github.com/evnm/03f8f12fe61ba8830a4f81623b8076ed
This branch is based on the jdbi-2.75 tag, which pulls in pgjdbc 9.1-901-1.jdbc4.
On Tue, Aug 23, 2016 at 11:35 AM, Evan Meagher <evan.meagher@gmail.com> wrote:
Sorry, I noticed that mistake after sending as well. The query statement I used included the `call` keyword, I just missed it when augmenting the simplified example code from my initial email.I modified by original jDBI DAO method with the `{call ...}` syntax thusly:@SqlBatch(transactional=true,value="{call append_to_time_series(...)}")public void insert(...);> Evan, it would be great if you could provide a self-contained test case that fails with "pre 1210" version so we won't accidentally break that behavior.I will see if I can tickle this issue with an addition to jDBI's test suite. It already has a few test classes that target specific corners of Postgres/pgjdbc. I'll update this thread once I have something replicable.--On Tue, Aug 23, 2016 at 11:25 AM, Vitalii Tymchyshyn <vit@tym.im> wrote:Correct syntax is {call procedure(params)}. I think you forgot "call".Пн, 22 серп. 2016 23:38 користувач Evan Meagher <evan.meagher@gmail.com> пише:> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS); 2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488#issuecomment- 237908650 ), however historical behavior was just fail with "A result was returned when none was expected" The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.Vladimir--Evan MeagherEvan Meagher
Evan Meagher
Evan,
we aren't going to ever fix 9.1-901 JDBC code is there any way to get jdbi to use a current driver ?
On 27 August 2016 at 15:06, Evan Meagher <evan.meagher@gmail.com> wrote:
I've created a branch which adds a test to jDBI's TestPreparedBatchGenerateKeysPostgres class which triggers the "A result was returned when none was expected" error: https://github.com/evnm/jdbi/ commit/ 407b3770fab7e606a88be44a5eb0e8 141b012e04 Here's the test output I'm seing locally: https://gist.github.com/evnm/ 03f8f12fe61ba8830a4f81623b8076 ed This branch is based on the jdbi-2.75 tag, which pulls in pgjdbc 9.1-901-1.jdbc4.--On Tue, Aug 23, 2016 at 11:35 AM, Evan Meagher <evan.meagher@gmail.com> wrote:Sorry, I noticed that mistake after sending as well. The query statement I used included the `call` keyword, I just missed it when augmenting the simplified example code from my initial email.I modified by original jDBI DAO method with the `{call ...}` syntax thusly:@SqlBatch(transactional=true,value="{call append_to_time_series(...)}")public void insert(...);> Evan, it would be great if you could provide a self-contained test case that fails with "pre 1210" version so we won't accidentally break that behavior.I will see if I can tickle this issue with an addition to jDBI's test suite. It already has a few test classes that target specific corners of Postgres/pgjdbc. I'll update this thread once I have something replicable.--On Tue, Aug 23, 2016 at 11:25 AM, Vitalii Tymchyshyn <vit@tym.im> wrote:Correct syntax is {call procedure(params)}. I think you forgot "call".Пн, 22 серп. 2016 23:38 користувач Evan Meagher <evan.meagher@gmail.com> пише:> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS); 2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488#issuecomment-237 908650 ), however historical behavior was just fail with "A result was returned when none was expected" The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.Vladimir--Evan MeagherEvan MeagherEvan Meagher
I've created a branch which adds a test to jDBI's TestPreparedBatchGenerateKeysPostgres class which triggers the "A result was returned when none was expected" error: https://github.com/evnm/jdbi/commit/407b3770fab7e606a88be44a5eb0e8141b012e04
Here's the test output I'm seing locally: https://gist.github.com/evnm/03f8f12fe61ba8830a4f81623b8076ed
This branch is based on the jdbi-2.75 tag, which pulls in pgjdbc 9.1-901-1.jdbc4.
On Tue, Aug 23, 2016 at 11:35 AM, Evan Meagher <evan.meagher@gmail.com> wrote:
Sorry, I noticed that mistake after sending as well. The query statement I used included the `call` keyword, I just missed it when augmenting the simplified example code from my initial email.I modified by original jDBI DAO method with the `{call ...}` syntax thusly:@SqlBatch(transactional=true,value="{call append_to_time_series(...)}")public void insert(...);> Evan, it would be great if you could provide a self-contained test case that fails with "pre 1210" version so we won't accidentally break that behavior.I will see if I can tickle this issue with an addition to jDBI's test suite. It already has a few test classes that target specific corners of Postgres/pgjdbc. I'll update this thread once I have something replicable.--On Tue, Aug 23, 2016 at 11:25 AM, Vitalii Tymchyshyn <vit@tym.im> wrote:Correct syntax is {call procedure(params)}. I think you forgot "call".Пн, 22 серп. 2016 23:38 користувач Evan Meagher <evan.meagher@gmail.com> пише:> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS); 2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488#issuecomment- 237908650 ), however historical behavior was just fail with "A result was returned when none was expected" The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.Vladimir--Evan MeagherEvan Meagher
Evan Meagher
The plot thickens. Upgrading jDBI to JDBC 9.4.1209 results in the test passing. Walking it back a few versions, it appears that the transition from 9.4.1207 to 9.4.1208 breaks the test.
Looking at the changelog of 9.4.1208, there are a couple changes related to callable and batch statement handling, but I'm not familiar enough with the codebase to make much immediate sense out of them:
On Sat, Aug 27, 2016 at 2:26 PM, Dave Cramer <pg@fastcrypt.com> wrote:
Evan,we aren't going to ever fix 9.1-901 JDBC code is there any way to get jdbi to use a current driver ?On 27 August 2016 at 15:06, Evan Meagher <evan.meagher@gmail.com> wrote:I've created a branch which adds a test to jDBI's TestPreparedBatchGenerateKeysPostgres class which triggers the "A result was returned when none was expected" error: https://github.com/evnm/jdbi/c ommit/407b3770fab7e606a88be44a 5eb0e8141b012e04 Here's the test output I'm seing locally: https://gist.github.com/evnm/03f8f12fe61ba8830a4f81 623b8076ed This branch is based on the jdbi-2.75 tag, which pulls in pgjdbc 9.1-901-1.jdbc4.--On Tue, Aug 23, 2016 at 11:35 AM, Evan Meagher <evan.meagher@gmail.com> wrote:Sorry, I noticed that mistake after sending as well. The query statement I used included the `call` keyword, I just missed it when augmenting the simplified example code from my initial email.I modified by original jDBI DAO method with the `{call ...}` syntax thusly:@SqlBatch(transactional=true,value="{call append_to_time_series(...)}")public void insert(...);> Evan, it would be great if you could provide a self-contained test case that fails with "pre 1210" version so we won't accidentally break that behavior.I will see if I can tickle this issue with an addition to jDBI's test suite. It already has a few test classes that target specific corners of Postgres/pgjdbc. I'll update this thread once I have something replicable.--On Tue, Aug 23, 2016 at 11:25 AM, Vitalii Tymchyshyn <vit@tym.im> wrote:Correct syntax is {call procedure(params)}. I think you forgot "call".Пн, 22 серп. 2016 23:38 користувач Evan Meagher <evan.meagher@gmail.com> пише:> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS); 2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488#issuecomment-237 908650 ), however historical behavior was just fail with "A result was returned when none was expected" The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.Vladimir--Evan MeagherEvan MeagherEvan Meagher
Evan Meagher
Evan,
we aren't going to ever fix 9.1-901 JDBC code is there any way to get jdbi to use a current driver ?
On 27 August 2016 at 15:06, Evan Meagher <evan.meagher@gmail.com> wrote:
I've created a branch which adds a test to jDBI's TestPreparedBatchGenerateKeysPostgres class which triggers the "A result was returned when none was expected" error: https://github.com/evnm/jdbi/ commit/ 407b3770fab7e606a88be44a5eb0e8 141b012e04 Here's the test output I'm seing locally: https://gist.github.com/evnm/ 03f8f12fe61ba8830a4f81623b8076 ed This branch is based on the jdbi-2.75 tag, which pulls in pgjdbc 9.1-901-1.jdbc4.--On Tue, Aug 23, 2016 at 11:35 AM, Evan Meagher <evan.meagher@gmail.com> wrote:Sorry, I noticed that mistake after sending as well. The query statement I used included the `call` keyword, I just missed it when augmenting the simplified example code from my initial email.I modified by original jDBI DAO method with the `{call ...}` syntax thusly:@SqlBatch(transactional=true,value="{call append_to_time_series(...)}")public void insert(...);> Evan, it would be great if you could provide a self-contained test case that fails with "pre 1210" version so we won't accidentally break that behavior.I will see if I can tickle this issue with an addition to jDBI's test suite. It already has a few test classes that target specific corners of Postgres/pgjdbc. I'll update this thread once I have something replicable.--On Tue, Aug 23, 2016 at 11:25 AM, Vitalii Tymchyshyn <vit@tym.im> wrote:Correct syntax is {call procedure(params)}. I think you forgot "call".Пн, 22 серп. 2016 23:38 користувач Evan Meagher <evan.meagher@gmail.com> пише:> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS); 2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488#issuecomment-237 908650 ), however historical behavior was just fail with "A result was returned when none was expected" The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.Vladimir--Evan MeagherEvan MeagherEvan Meagher
The plot thickens. Upgrading jDBI to JDBC 9.4.1209 results in the test passing. Walking it back a few versions, it appears that the transition from 9.4.1207 to 9.4.1208 breaks the test.
Looking at the changelog of 9.4.1208, there are a couple changes related to callable and batch statement handling, but I'm not familiar enough with the codebase to make much immediate sense out of them:
On Sat, Aug 27, 2016 at 2:26 PM, Dave Cramer <pg@fastcrypt.com> wrote:
Evan,we aren't going to ever fix 9.1-901 JDBC code is there any way to get jdbi to use a current driver ?On 27 August 2016 at 15:06, Evan Meagher <evan.meagher@gmail.com> wrote:I've created a branch which adds a test to jDBI's TestPreparedBatchGenerateKeysPostgres class which triggers the "A result was returned when none was expected" error: https://github.com/evnm/jdbi/c ommit/407b3770fab7e606a88be44a 5eb0e8141b012e04 Here's the test output I'm seing locally: https://gist.github.com/evnm/03f8f12fe61ba8830a4f81 623b8076ed This branch is based on the jdbi-2.75 tag, which pulls in pgjdbc 9.1-901-1.jdbc4.--On Tue, Aug 23, 2016 at 11:35 AM, Evan Meagher <evan.meagher@gmail.com> wrote:Sorry, I noticed that mistake after sending as well. The query statement I used included the `call` keyword, I just missed it when augmenting the simplified example code from my initial email.I modified by original jDBI DAO method with the `{call ...}` syntax thusly:@SqlBatch(transactional=true,value="{call append_to_time_series(...)}")public void insert(...);> Evan, it would be great if you could provide a self-contained test case that fails with "pre 1210" version so we won't accidentally break that behavior.I will see if I can tickle this issue with an addition to jDBI's test suite. It already has a few test classes that target specific corners of Postgres/pgjdbc. I'll update this thread once I have something replicable.--On Tue, Aug 23, 2016 at 11:25 AM, Vitalii Tymchyshyn <vit@tym.im> wrote:Correct syntax is {call procedure(params)}. I think you forgot "call".Пн, 22 серп. 2016 23:38 користувач Evan Meagher <evan.meagher@gmail.com> пише:> Let us know how the call syntax works out for you
Using `{append_to_time_series(...)}` results in a o.p.u.PSQLException with message 'ERROR: syntax error at or near "{"'> Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?That works! In fact, on 9.4.1210-SNAPSHOT, it works with and without the @GetGeneratedKeys annotation.I guess I'll just stay tuned for a stable 9.4.1210 release and make do with the snapshots in the meantime. Thanks to all for the responses, and thanks Vladimir for the workaround!On Fri, Aug 19, 2016 at 8:00 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Evan>However, because Postgres functions are invoked using SELECT, they return a table-like result, so even though my PL/pgSQL function returns VOID, the queries fail in the JDBC driver because it's expecting a null result.Evan,Can you please try the latest pgjdbc 9.4.1210-SNAPSHOT + @GetGeneratedKeys near your @SqlBatch("select ...") kind of statement?The idea is as follows:1) jDBI would issue prepareStatement(..., Statement.RETURN_GENERATED_KEYS); 2) pgjdbc has recently learned to handle "return generated keys" better, so that "return_generated_keys" would hint pgjdbc that it should expect some response (including empty rowset), so it won't fail with "none was expected".Technically speaking, the question "if pgjdbc should fail when unexpected row data comes in a response to a query" was raised (see https://github.com/pgjdbc/pgjdbc/issues/488#issuecomment-237 908650 ), however historical behavior was just fail with "A result was returned when none was expected" The solution is to use proper API when executing statements that return something. For instance: executeQuery, or use "generated keys" API.Vladimir--Evan MeagherEvan MeagherEvan Meagher
Evan Meagher