Re: Patch for - Change FETCH/MOVE to use int8

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Dhanaraj M <Dhanaraj(dot)M(at)Sun(dot)COM>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Patch for - Change FETCH/MOVE to use int8
Date: 2006-08-14 02:09:04
Message-ID: 11877.1155521344@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> I'm not sure that I see the point of this at all. ISTM the entire
>> reason for using a cursor is that you're going to fetch the results
>> in bite-size pieces. I don't see the current Postgres source code
>> surviving into the era where >2G rows is considered bite-size ;-)

> Think MOVE to a specific section of the cursor > 2gig. I can see that
> happening.

Yeah, and by the time it happens you'll have gotten bored and found
something else to do. With no support in the system for random access
to a cursor result, this is just about as useless as the FETCH case.

In any case I agree with Alvaro's comment: the way to support int8 in
a FETCH/MOVE command is not to try to convert the entire rest of the
grammar to int8 instead of int4 as its native datatype.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-08-14 02:27:37 Re: [PATCHES] Custom variable class segmentation fault
Previous Message Bruce Momjian 2006-08-14 02:05:59 Re: [PATCHES] extension for sql update

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-08-14 02:27:37 Re: [PATCHES] Custom variable class segmentation fault
Previous Message Bruce Momjian 2006-08-14 02:05:59 Re: [PATCHES] extension for sql update