From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Maximum query string length |
Date: | 1999-07-23 00:34:43 |
Message-ID: | 11049.932690083@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za> writes:
> Massimo wrote:
>>> you will anyway have troubles with lex and yacc
> Well, if the query length is limited by yacc, bison, lex, or any other tools
> that we use, is it worthwhile trying to make it dynamic?
Yes, I think so. We have not yet tried hard to persuade those tools to
cooperate, but I find it hard to believe that they cannot be handed a
source string in an externally supplied buffer. At worst, we might find
that we can only promise > 64K query length when using a bison-generated
parser (since the parser innards tend to vary a lot across vendor
yaccs).
lex may or may not be worth worrying about --- the buffer size limit it
would impose would be for a single token, I believe, not for the whole
query.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-07-23 00:52:39 | Re: [HACKERS] Phantom row from aggregate in self-join in 6.5 |
Previous Message | Tom Lane | 1999-07-23 00:30:31 | Re: [INTERFACES] Frontend/Backend Protocol |