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: