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(at)pop(dot)dn(dot)net]
>> Sent: Wednesday, July 14, 1999 5:56 PM
>> To: Tom Lane; pgsql-hackers(at)postgreSQL(dot)org
>> Subject: Re: [HACKERS] MAX Query length
>>
>>
>> Tom Lane wrote:
>> >
>> > "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)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
>>