| 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: | Whole Thread | Raw Message | 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 |