Thread: RE: Postgres 7.0 JDBC - update count for DELETE is a lways 1
RE: Postgres 7.0 JDBC - update count for DELETE is a lways 1
From
Gregory Krasnow OpenSourceCRM
Date:
This is a little off-topic, but I have been unable to get in through anonymous cvs. I have tried:cvs -d :pserver:anoncvs@hub.org:/usr/local/cvsroot login with postgresql as the password - Greg -----Original Message----- From: Joseph Shraibman [mailto:jks@selectacast.net] Sent: Monday, June 05, 2000 10:48 AM To: Stephen Crawley Cc: pgsql-interfaces@postgresql.org Subject: Re: [INTERFACES] Postgres 7.0 JDBC - update count for DELETE is always 1 This was supposed to be fixed already, but I guess this is just more code that didn't get into the cvs when it should have. Stephen Crawley wrote: > > Hi, > > I'm trying to port a large JDBC application to Postgres 7.0 from MySQL, > and I've run into what I believe is a bug in the JDBC driver. > > When my application executes a "DELETE" statement, the ResultSet entry > always says that 1 row has been deleted. Even when nothing has been > deleted. I did a bit of investigation, and I think I've found where the > problem is. In the class postgresql.Connection, the method > > public java.sql.ResultSet ExecSQL(String sql) throws SQLException > > contains the following code: > > ... > > int update_count = 1; > > ... > > case 'C': // Command Status > recv_status = pg_stream.ReceiveString(8192); > > // Now handle the update count correctly. > if(recv_status.startsWith("INSERT") || recv_status.startsWith("UPDATE")) { > try { > update_count = > Integer.parseInt(recv_status.substring(1+recv_status.lastIndexOf(' > '))); > } catch(NumberFormatException nfe) { > throw new PSQLException("postgresql.con.fathom",recv_status); > } > } > > ... > > It looks like the code picks out the update count when the query was > described (by the backend) as an INSERT or UPDATE. But it does not > do this for a DELETE. > > I looked at the source of the backend (src/backend/tcop/dest.c, etc) and > it does seem to return an update count for the CMD_DELETE command. If > I've got this right, adding > > ... || recv_status.startsWith("DELETE") ... > > to the if statement should fix the problem. > > -- Steve > >
Gregory Krasnow OpenSourceCRM wrote: > > This is a little off-topic, but I have been unable to get in through > anonymous cvs. > I have tried: > cvs -d :pserver:anoncvs@hub.org:/usr/local/cvsroot login > > with postgresql as the password > > - Greg > I don't know much about cvs, but the file below works for me with the command 'cvsup pgsql.cvsup' #file: pgsql.cvsup # CVSup distribution file for the PostgreSQL ORDBMS project # Modified by lockhart@alumni.caltech.edu 1997-08-28 # - Point to my local snapshot source tree # # Defaults that apply to all the collections *default host=postgresql.org *default compress *default release=cvs *default delete use-rel-suffix *default tag=. #*default tag=REL6_5_3 #*default date=2000.02.20.00.00.00 # base directory points to where CVSup will store its 'bookmarks' file(s) # will create subdirectory sup/ #*default base=/opt/postgres # /usr/local/pgsql *default base=/usr/src/cvs #*default base=/var/lib/pgsql # prefix directory points to where CVSup will store the actual distribution(s) #*default prefix=/opt/postgres/cvs # /usr/local/pgsql *default prefix=/usr/src/cvs #*default prefix=/var/lib/pgsql # complete distribution, including all below pgsql # individual distributions vs 'the whole thing' # pgsql-doc # pgsql-perl5 # pgsql-src # end file
Gregory Krasnow OpenSourceCRM <gak@opensourcecrm.org> writes: > This is a little off-topic, but I have been unable to get in through > anonymous cvs. > I have tried: > cvs -d :pserver:anoncvs@hub.org:/usr/local/cvsroot login The cvsroot directory at hub was moved a few weeks ago. It's now /home/projects/pgsql/cvsroot. regards, tom lane