RE: [HACKERS] MAX Query length

I was just thinking of removing the limit completely.  The query would fail
when it could allocate more memory for the query string.

MikeA

>> -----Original Message-----
>> From: Bernard Frankpitt [mailto:frankpit@pop.dn.net]
>> Sent: Wednesday, July 14, 1999 5:56 PM
>> To: Tom Lane; pgsql-hackers@postgreSQL.org
>> Subject: Re: [HACKERS] MAX Query length
>> 
>> 
>> Tom Lane wrote:
>> > 
>> > "Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
>> > > Trawling through the code last night I noticed that:
>> > > #define MAX_QUERY_SIZE (BLCKSZ * 2)
>> > 
>> >
>> > Sure: you want to be able to INSERT a tuple of maximum 
>> size.  In the
>> > absence of dynamically sized text buffers, a reasonable estimate of
>> > the longest INSERT command of interest is going to depend 
>> on BLCKSZ.
>> ...
>> >                         regards, tom lane
>> 
>> While I agree that it is reasonable that the query size should be
>> dependent on the block-size, there is an assumption here that the
>> type_in() and type_out() routines that do not expand the size of the
>> ascii representation of the tuple data in the query string 
>> to more than
>> twice is size in it's internal disk representation.  An important
>> exception to this assumption would be large arrays of floating point
>> data that are stored with limited precision.  A 
>> (single-precision) float
>> takes 4 bytes of space in a  disk  block, yet the ascii 
>> representation
>> for the same data before conversion could easily take in excess of 16
>> bits if it comes from a 
>> piece of code  like 
>> 
>>         double x;
>>     int buf_pos
>>  ....
>>  ....
>>     buf_pos += 
>>       snprintf( &query_buf[buf_pos], (l_buf - buf_pos ), "%e", x);  
>> 
>> somewhere in a front end.  Perhaps it would be a good idea 
>> to increase
>> the multiplier in 
>> 
>>     #define MAX_QUERY_SIZE (BLCKSZ * 2)
>> 
>> 
>> to something larger than 2.
>> 
>> Bernie Frankpitt
>>