Skip site navigation (1) Skip section navigation (2)

Re: [JDBC] Re: 'on insert do instead' rule with a where clause responds 'INSERT 0 0'

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Julius Stroffek <Julius(dot)Stroffek(at)Sun(dot)COM>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-jdbc(at)postgresql(dot)org, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [JDBC] Re: 'on insert do instead' rule with a where clause responds 'INSERT 0 0'
Date: 2007-10-18 20:59:57
Message-ID: 4717C94D.7030605@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-jdbc
Julius Stroffek wrote:

> There is only one option that comes to my mind - always return 
> Statment.SUCCESS_NO_INFO in executeBatch (or possibly only depending on 
> some java property). I can not see any simple solution for 
> Statement.executeUpdate since the number of rows affected may differ 
> depending on the rules and might be also difficult to calculate.

The server is reporting to the driver that zero rows were affected (not 
"unknown", *zero*) so I don't see any reason why the driver should not 
report that as the number of rows affected.

Returning SUCCESS_NO_INFO reduces the usefulness of the driver in the 
other 98% of cases where there are no INSTEAD rules.

The protocol docs say:

> CommandComplete (B)
[...]
>         For an INSERT command, the tag is INSERT oid rows, where rows is the number of rows inserted. oid is the object ID of the inserted row if rows is 1 and the target table has OIDs; otherwise oid is 0.

So if the server is not returning "the number of rows inserted" then 
either the server has a bug or the protocol docs are wrong.

-O

In response to

pgsql-bugs by date

Next:From: Kris JurkaDate: 2007-10-18 23:24:57
Subject: Re: creating a table with a serial column sets currval
Previous:From: Tom LaneDate: 2007-10-18 20:48:45
Subject: Re: creating a table with a serial column sets currval

pgsql-jdbc by date

Next:From: Andrei IlitchevDate: 2007-10-18 21:01:12
Subject: Re: Fw: postgresql experts please help
Previous:From: Michael SchmidtDate: 2007-10-18 20:20:06
Subject: Re: Fw: postgresql experts please help

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group