Thread: Re: [PATCHES] Patch for - Change FETCH/MOVE to use int8
Alvaro Herrera <alvherre@commandprompt.com> writes: > I don't think this is the right approach. Maybe it would be reasonable > to add another arm to the %union instead, not sure. The problem is the > amount of ugly casts you have to use below. The scanner code seems to > think that a constant larger than the biggest int4 should be treated as > float, so I'm not sure why this would work anyway. 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 ;-) I thought the int8-LIMIT patch was equally pointless, btw, but at least it was not very invasive. This one is not passing the minimum usefulness-to-ugliness ratio for me. regards, tom lane
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > I don't think this is the right approach. Maybe it would be reasonable > > to add another arm to the %union instead, not sure. The problem is the > > amount of ugly casts you have to use below. The scanner code seems to > > think that a constant larger than the biggest int4 should be treated as > > float, so I'm not sure why this would work anyway. > > 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. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.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