Planning final assault on query length limits

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: meskes(at)postgreSQL(dot)org (Michael Meskes)
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Planning final assault on query length limits
Date: 1999-10-20 15:38:00
Message-ID: 12950.940433880@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

AFAICT, the last remaining textual length limits in the backend are a
couple of fixed-size buffers in rewriteDefine.c and array support.
In the next few days (probably this weekend) I intend to fix that code
and then remove all #define constants that have anything to do with
string length limits. (Tentative hit list is attached.)

Although the backend is in fairly good shape, there are parts of
interfaces/ and bin/ that are not. In particular:

pg_dump has a lot of uses of MAX_QUERY_SIZE. I believe Michael Ansley
is working on revising pg_dump to use expansible string buffers, so for
now I will leave that code alone (I'll just temporarily stick a
definition of MAX_QUERY_SIZE into pg_dump.h).

ecpg's lexer needs the same fixes recently applied to parser/scan.l to
eliminate a fixed-size literal buffer and allow flex's input buffer to
grow as needed. Michael Meskes usually handles ecpg --- Michael, do
you want to deal with this issue or shall I take a cut at it?

The odbc, python, and cli interfaces will all break because they contain
references to symbols I propose to remove. Since I don't use any of
these, and they aren't built by default, I can face this prospect
without flinching ;-). This is a call for whoever maintains these
modules to get busy.

ODBC will probably need some actual thought, since what it seems to be
doing with these symbols is making their values available to client
programs on request. Does ODBC's API for this function have a concept
of "no specific upper limit"?

regards, tom lane

Say goodnight to:

MAX_PARSE_BUFFER
MAX_QUERY_SIZE
ERROR_MSG_LENGTH
MAX_LINES
MAX_STRING_LENGTH
REMARK_LENGTH
ELOG_MAXLEN
MAX_BUFF_SIZE
PQ_BUFFER_SIZE
MAXPGPATH
MAX_STRING_LENGTH
YY_BUF_SIZE remove hacking in makefiles
YY_READ_BUF_SIZE no need to alter default
MaxHeapTupleSize (not used)
MaxAttributeSize (not used)
MaxAttrSize (where used for buffer sizing)

Suspicious-looking symbols found only in various interfaces/ dirs;
I don't plan to remove these but someone should:

SQL_PACKET_SIZE odbc
MAX_MESSAGE_LEN interfaces/cli, odbc
MAX_STATEMENT_LEN odbc
TEXT_FIELD_SIZE odbc
MAX_VARCHAR_SIZE odbc
DRV_VARCHAR_SIZE odbc
DRV_LONGVARCHAR_SIZE odbc
MAX_CONNECT_STRING odbc
MAX_BUFFER_SIZE interfaces/python
MAX_FIELDS odbc (does this relate to anything real?)

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-10-20 15:42:33 Re: [HACKERS] Readline use in trouble?
Previous Message Brook Milligan 1999-10-20 15:37:49 Re: [HACKERS] Readline use in trouble?