RE: [HACKERS] Problem with query length - Mailing list pgsql-hackers

From Ansley, Michael
Subject RE: [HACKERS] Problem with query length
Date
Msg-id 1BF7C7482189D211B03F00805F8527F70ED115@S-NATH-EXCH2
Whole thread Raw
In response to [HACKERS] Problem with query length  ("Natalya S. Makushina" <mak@rtsoft.msk.ru>)
List pgsql-hackers
To further this thread:

I have downloaded an example implementation of SQL which, thankfully, does
not use vltc's.  I'm going to see where we have problems, and see if I can
reduce the scanner rules to something that is not variable-length trailing.

If anybody with significant scanner/language/parse experience (i.e. more
than mine == zero) has some pearls of wisdom to add, please feel free.  I'm
a little out of my depth here, and I'm a bit nervous to go changing the
scanner.


MikeA


>> -----Original Message-----
>> From: Natalya S. Makushina [mailto:mak@rtsoft.msk.ru]
>> Sent: Thursday, August 19, 1999 10:39 AM
>> To: 'Ansley, Michael'; 'pgsql-hackers@postgreSQL.org'
>> Subject: [HACKERS] Problem with query length
>> 
>> 
>>       Hello 
>> 
>> Thank's very much for your help.
>> 
>> I have already installed two copies of PostgreSQL DB. One 
>> was installed from RPM, another one was compiled without 
>> RPM. The copy installed from RPM has problem with query 
>> length, another copy haven't this problem! 
>> 
>> I decide to compile it from sources and try to use. After 
>> compilation all is OK! Query length is 8191 now.
>> 
>>       May be error presents in RPM.
>> 
>> From :        Ansley, Michael 
>> [SMTP:Michael.Ansley@intec.co.za]
>> Date :         18 августа 1999 г. 11:55
>> To :        'Natalya S. Makushina'; 'pgsql-hackers@postgreSQL.org'
>> Subject :        RE: [HACKERS] Problem with query length
>> 
>> Hi, all
>> 
>> I have found out what the problem is, although not (yet) the 
>> solution.  
>> 
>> Executive summary:
>> ------------------
>> The scan.l code is not flexing as intended.  This means 
>> that, for most
>> production installations, the max token size is around 64kB.
>> 
>> Technical summary:
>> ------------------
>> The problem is that scan.l is compiling to scan.c with 
>> YY_USES_REJECT being
>> defined.  When YY_USES_REJECT is defined, the token buffer is NOT
>> expandable, and the parser will fail if expansion is 
>> attempted.  However,
>> YY_USES_REJECT should not be defined, and I'm trying to work 
>> out why it is.
>> I have posted to the flex mailing list, and expect a reply 
>> within the next
>> day or so.
>> 
>> The bottom line:
>> ------------------
>> The token limit seems to be effectively the size of 
>> YY_BUF_SIZE in scan.l,
>> until I submit a patch which should make it unlimited.  
>> 
>> 
>> MikeA
>> 
>> >> -----Original Message-----
>> >> From: Natalya S. Makushina [mailto:mak@rtsoft.msk.ru]
>> >> Sent: Tuesday, August 17, 1999 3:15 PM
>> >> To: 'pgsql-hackers@postgreSQL.org'
>> >> Subject: [HACKERS] Problem with query length
>> >> 
>> >> 
>> >> -------------------------------------------------------------
>> >> ----------------------------------------------------------------
>> >> I have posted this mail to psql-general.  But i didn't get 
>> >> any answer yet.
>> >> -------------------------------------------------------------
>> >> ----------------------------------------------------------------
>> >> 
>> >> When i had tried to insert into text field text (length 
>> >> about 4000 chars), the backend have crashed with status 139. 
>> >> This error is happened when the query length ( SQL query) is 
>> >> more than 4095 chars. I am using PostgreSQL 6.4.2 on Linux.
>> >> 
>> >> My questions are:
>> >> 1. Is there problem with text field or with length of SQL query?
>> >> 2. Would postgresql have any limits for SQL query length?
>> >> I checked the archives but only found references to the 8K 
>> >> limit. Any help would be greatly appreciated.
>> >> Thanks for help
>> >>                 Natalya Makushina 
>> >>                 mak@rtsoft.msk.ru
>> >> 
>> >> 
>> 
>> ************
>> Check out "PostgreSQL Wearables" @ http://www.pgsql.com
>> 


pgsql-hackers by date:

Previous
From: "Ansley, Michael"
Date:
Subject: RE: [HACKERS] Postgres' lexer
Next
From: "F.J. Cuberos"
Date:
Subject: Statement Triggers Patch