Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id MAA34657
	for <pgsql-interfaces@postgreSQL.org>;
	Tue, 13 Jul 1999 12:43:27 -0400 (EDT)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA23457;
	Tue, 13 Jul 1999 12:42:50 -0400 (EDT)
To: Matthew Hagerty <matthew@venux.net>
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] 8K query limit in 6.5? 
In-reply-to: Your message of Tue, 13 Jul 1999 12:02:18 -0400
	<4.1.19990713115720.009c84b0@mail.venux.net>
Date: Tue, 13 Jul 1999 12:42:50 -0400
Message-ID: <23455.931884170@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Matthew Hagerty <matthew@venux.net> writes:
> ... please make this bigger!  Or tell me how and I'll do it. :)

"Find all the places that need fixing, and fix 'em." :-)
The devil is in the details ... and there are a lot of details.
You could probably get some useful functionality just by fixing
frontend libpq's output buffer and the query input buffer in
backend/tcop/postgres.c.  The trouble comes in cleaning up all the
details, like fixed-size buffers in COPY, pg_dump, etc etc etc etc.

Michael Ansley seems to be interested in working on this; I'd
suggest getting together with him if you want to help.

> Is it really such a big deal to increase the size of a query that pg can
> handle?  I'm talking about the size of a query submitted to pg, from what I
> understand there is no limit on the record (tuple) size that can be
> returned from pg.  Is my understanding correct?

There is a (quite unrelated) limit on the size of a tuple that can be
stored on disk, but AFAIK you can construct an arbitrarily large tuple
as the result of computations specified in a SELECT and it will be
passed back to your frontend application without trouble; as long as
you don't run out of memory on either side, that is.

Where we want to end up, of course, is no limit on the size of a disk
tuple either, but the code changes for that are almost entirely
unrelated to the ones that deal with the textual length of a query.
It's best tackled as two independent projects.

			regards, tom lane