Planning final assault on query length limits

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?)