Thread: Max query string length

Hi,

Well, I got psql to work with arbitrary query string lengths, eventually, by
implementing an expandable buffer struct.  Unfortunately, I didn't bring the
stuff to work today, so it'll only be in the patches tomorrow.
This means that the query buffer length will not be restricted in psql.
Next up is libpq.  I checked the code for this, and there seems to be only
one place where this is an issue, and it is just a (redundant?) check on the
length of the string to ensure that it is still within the limit.  I removed
the check, which then seemed to allow a large query string through to the
back end.  I received a message like this:
ERROR:  parser: parse error at or near ""

So, I assumed that it was making it as far as the parser.  So now I have to
dive into the backend, and make sure that it can accept arbitrary length
queries, right?  My first take, strategy-wise, is going to be to go through
the diagram detailing the design of the back end, and take it piece by
piece.  Any fundamental flaws in this?

As far as the buffer struct, and code goes, is there anything around which
does this already?  If not, I thought of placing it somewhere where all the
modules can access it, as I will probably land up using it in more places
than just psql.  Thoughts, screams of laughter, etc....

Lastly, when I ran configure, I included the --enable-cassert switch.
However, this does not seem to force the compiler to include debug info,
i.e.: --enable-debug.  I tried the --enable-debug switch as well, but it
didn't seem to have any effect.  Am I missing something?

Thanks


MikeA

"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
> As far as the buffer struct, and code goes, is there anything around which
> does this already?  If not, I thought of placing it somewhere where all the
> modules can access it, as I will probably land up using it in more places
> than just psql.  Thoughts, screams of laughter, etc....

There is a simple expansible-string module in the backend already;
see backend/lib/stringinfo.c.  It could use some improvements but
I'd suggest enhancing it rather than making another one.

> Lastly, when I ran configure, I included the --enable-cassert switch.
> However, this does not seem to force the compiler to include debug info,
> i.e.: --enable-debug.  I tried the --enable-debug switch as well, but it
> didn't seem to have any effect.  Am I missing something?

There is no --enable-debug switch.  You have to turn on debug by
modifying the CFLAGS line in the template file for your system.
(Hmm, now that you mention it, --enable-debug would be a cleaner
solution than keeping a locally modified template file, which is
what I currently do and most of the other developers probably do
also ... another to-do item ...)
        regards, tom lane

> There is no --enable-debug switch.  You have to turn on debug by
> modifying the CFLAGS line in the template file for your system.
> (Hmm, now that you mention it, --enable-debug would be a cleaner
> solution than keeping a locally modified template file, which is
> what I currently do and most of the other developers probably do
> also ... another to-do item ...)

What debugs would --enable-debug enable?

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> (Hmm, now that you mention it, --enable-debug would be a cleaner
>> solution than keeping a locally modified template file, which is
>> what I currently do and most of the other developers probably do
>> also ... another to-do item ...)

> What debugs would --enable-debug enable?

Good question.  I was just thinking of adding -g to CFLAGS.
What else would you want to do?
        regards, tom lane