Thread: executeUpdate API contract. Return value equals 0.
Hi, I have seen there have been conversations about the returned value from executeUpdate when using partitioned tables. This thread places the issue in the postgres-server court: http://www.postgresql.org/message-id/013901c5fad9$1c18c600$ca78a8c0@yawin.yesasia.com and another coversation on the pgsql-bugs mailing list that seems to bat the problem back at the pgjdbc driver :) I have written a test case for the driver and made it available on GitHub. It is compatible with the current testsuit. It is there for you to consider it's merits and use it if considered useful. I would like to think it gives this issue visibility. https://github.com/whitingjr/pgjdbc/tree/partitioned_table_test Is the best way to progress this issue is to raise it again on pgsql-bugs list ? Regards, Jeremy -- Jeremy Whiting Senior Software Engineer, Middleware Performance Team Red Hat ------------------------------------------------------------ Registered Address: Red Hat UK Ltd, 64 Baker Street, 4th Floor, London. W1U 7DF. United Kingdom. Registered in England and Wales under Company Registration No. 03798903. Directors: Michael Cunningham (USA), Mark Hegarty(Ireland), Matt Parson (USA), Charlie Peters (USA)
On 02/26/2013 09:15 PM, Jeremy Whiting wrote: > Hi, > I have seen there have been conversations about the returned value from > executeUpdate when using partitioned tables. This thread places the > issue in the postgres-server court: > > http://www.postgresql.org/message-id/013901c5fad9$1c18c600$ca78a8c0@yawin.yesasia.com > > and another coversation on the pgsql-bugs mailing list that seems to > bat the problem back at the pgjdbc driver :) Really? I either didn't see that thread or forgot it. Link? I don't see how PgJDBC can return rowcounts when trigger-based partitioning doesn't produce them. > > I have written a test case for the driver and made it available on > GitHub. It is compatible with the current testsuit. It is there for you > to consider it's merits and use it if considered useful. I would like to > think it gives this issue visibility. > > https://github.com/whitingjr/pgjdbc/tree/partitioned_table_test The test case looks reasonable to me at a quick scan; haven't merged and run it yet. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 01/03/13 04:51, Craig Ringer wrote: > On 02/26/2013 09:15 PM, Jeremy Whiting wrote: >> Hi, >> I have seen there have been conversations about the returned value from >> executeUpdate when using partitioned tables. This thread places the >> issue in the postgres-server court: >> >> http://www.postgresql.org/message-id/013901c5fad9$1c18c600$ca78a8c0@yawin.yesasia.com >> >> and another coversation on the pgsql-bugs mailing list that seems to >> bat the problem back at the pgjdbc driver :) > Really? I either didn't see that thread or forgot it. Link? Sorry for the delay. Tracked down the email thread and I think I have my facts sightly wrong regarding who said what. The thread was initially raised in the context of using Hibernate. Hibernate was reporting a problem. http://www.postgresql.org/message-id/000801cd9b5a$12717600$37546200$@radiantblue.com Though the cause of the error was attributed to Hibernate by Jaime. http://www.postgresql.org/message-id/CAJKUy5i6_pxNmvzu+JTXaoWy3eEynNFdrOnGdNPPoh1XbeZmQA@mail.gmail.com > I don't see how PgJDBC can return rowcounts when trigger-based > partitioning doesn't produce them. So any sanity checks by Hibernate will result in an assertion failure. >> I have written a test case for the driver and made it available on >> GitHub. It is compatible with the current testsuit. It is there for you >> to consider it's merits and use it if considered useful. I would like to >> think it gives this issue visibility. >> >> https://github.com/whitingjr/pgjdbc/tree/partitioned_table_test > The test case looks reasonable to me at a quick scan; haven't merged and > run it yet. >
On 03/05/2013 10:38 PM, Jeremy Whiting wrote: >> > I don't see how PgJDBC can return rowcounts when trigger-based >> > partitioning doesn't produce them. > So any sanity checks by Hibernate will result in an assertion failure. Correct, and we know that's ... less than ideal. Unfortunately, improving it isn't really possible until true partitioning is implemented in the server to replace the current table inheritance and trigger based approach. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services