RE: [HACKERS] Lex and things...

>>
>> Ansley, Michael wrote:
>> >
>> > As far as I understand it, the MAX_PARSE_BUFFER limit only applies if
char
>> > parsestring[] is used, not if char *parsestring is used. This is the
whole
>> > reason for using flex. And scan.l is set up to compile using char
>> > *parsestring, not char parsestring[].
>> >
>>
>> What is defined explicitly:
>>
>> #ifdef YY_READ_BUF_SIZE
>> #undef YY_READ_BUF_SIZE
>> #endif
>> #define YY_READ_BUF_SIZE MAX_PARSE_BUFFER
>>
>> (these strings are repeated twice :)
I noticed that, but hey, who am I to argue.

>>
>> ...
>> char literal[MAX_PARSE_BUFFER];
>>
>> ...
>> <xq>{xqliteral} {
>> if ((llen+yyleng) >
>> (MAX_PARSE_BUFFER - 1))
>>
>> elog(ERROR,"quoted string parse buffer of %d chars
>> exceeded",MAX_PARSE_BUFFER);
>> memcpy(literal+llen,
>> yytext, yyleng+1);
>> llen += yyleng;
>> }
>>
>> Seems that limits are everywhere ;)
>>
>> --
>> Leon.
I think we can turn literal into a char *, if we change the code for
<xq>{xqliteral}. This doesn't look like it will be too much of a mission,
but the outer limit is going to be close to the block size, because tuples
can't expand past the end of a block. I think that it would be wise to
leave this limit in place until such time as the tuple size limit is fixed.
Then we can remove it.

So, for the moment, I think we can consider the job pretty much done, apart
from bug-fixes. We can revisit the MAX_PARSE_BUFFER limit when tuple size
is delinked from block size. My aim with this work was to remove the
general limit on the length of a query string, and that has basically been
achieved. We have, as a result of the work, come across other limits, but
those have dependencies, and will have to wait.

Cheers...

MikeA