Re: [HACKERS] Maximum query string length

From: "Mark Hollomon" <mhh(at)nortelnetworks(dot)com>
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-22 12:39:28
Message-ID: 37971100.84959A0F@americasm01.nt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ansley, Michael wrote:
>
> Massimo wrote:
> >> A better way would be to allocate and grow query buffers dynamically
> while
> >> reading the query but you will anyway have troubles with lex and yacc
> which
> >> use statically allocated buffers whose size is hardwired in the program.
> >> This is why I had to make those ugly changes in the Makefiles.
>
> 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? If I can still
> only get a 64k query into the backend, what use is there in creating a 800k
> query in psql?
>
> Thought and/or bright ideas or welcomed...
>
> MikeA

That shouldn't be hard to fix. Though it might be hard to fix with good
performance. The default input routines in lex fill its internal buffer
with
a 'line' of text. But all those routines can be overridden. So you could
make lex read directly from the dynamic buffer. Look at yyinput (or is
it yy_input - can't remember).

If you do that, I think the only limitation will be on the size of a
single token. I don't know how postgresql handles quoted text and
comments,
but that would be where the problem may arise.

--

Mark Hollomon
mhh(at)nortelnetworks(dot)com
ESN 451-9008 (302)454-9008

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Malcolm Beattie 1999-07-22 13:38:19 Phantom row from aggregate in self-join in 6.5
Previous Message Vadim Mikheev 1999-07-22 12:12:52 Re: [HACKERS] GRANT suggestion