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

Re: Re: [HACKERS] Outstanding patches

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL jdbc list <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Re: [HACKERS] Outstanding patches
Date: 2001-06-07 00:08:03
Message-ID: 200106070008.f57083G28044@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-jdbc
> > +			/* I use CMD_UPDATE, because no CMD_MOVE or the like
> > +			   exists, and I would like to provide the same
> > +			   kind of info as CMD_UPDATE */
> > +			UpdateCommandInfo(CMD_UPDATE, 0, -1*estate->es_processed);
> 
> I do not think it is a good idea to return a negative count for a
> backwards move; that is too likely to break client code that parses
> command result strings and isn't expecting minus signs.  The client
> should know whether he issued MOVE FORWARD or MOVE BACKWARDS anyway,
> so just returning es_processed ought to be sufficient.
> 
> Otherwise I think the patch is probably OK.

I have applied this patch with does MOVE output for both the backend and
jdbc.  I tested the JDBC patch by compiling, and changed the backend to
only output postitive values.

Thanks.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Mark StosbergDate: 2001-06-07 01:00:45
Subject: behavior of ' = NULL' vs. MySQL vs. Standards
Previous:From: Alex PilosovDate: 2001-06-06 23:27:50
Subject: Re: [HACKERS] something smells bad

pgsql-jdbc by date

Next:From: Joseph ShraibmanDate: 2001-06-07 00:21:19
Subject: Re: jdbc3
Previous:From: Bruce MomjianDate: 2001-06-06 21:15:40
Subject: Finalize large object patch

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