*got* to be pointless.

Only lightly tested as yet, since libpq doesn't know anything about 'em.

Per recent discussion on pgsql-general, this is appropriate for spec
compliance, and has the nice side-effect of easing porting from old
pg_dump files that exhibit the 59.999=>60.000 roundoff problem.

implementation limits, do not issue an ERROR; instead issue a NOTICE and use
the max supported value.  Per pgsql-general discussion of 28-Apr, this is
needed to allow easy porting from pre-7.3 releases where the limits were
higher.

Unrelated change in same area: accept GLOBAL TEMP/TEMPORARY as a synonym
for TEMPORARY, as per pgsql-hackers discussion of 15-Apr.  We previously
rejected it, but that was based on a misreading of the spec --- SQL92's
GLOBAL temp tables are really closer to what we have than their LOCAL ones.

per report from Olivier Prenant.  Also fix off-by-one space calculation
in ReadToc; this woould not have hurt us until we had more than 100
dependencies for a single object, but wrong is wrong.

(agollapudi@demandsolutions.com).
Also applied the RefCursor support patch by Nic Ferrier.  This patch allows
you too return a get a result set from a function that returns a refcursor.
For example:
call.registerOutParameter(1, Types.OTHER);
call.execute();
ResultSet rs = (ResultSet) call.getObject(1);

Modified Files:
 	jdbc/org/postgresql/core/BaseStatement.java
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
 	jdbc/org/postgresql/jdbc1/Jdbc1CallableStatement.java
 	jdbc/org/postgresql/jdbc1/Jdbc1PreparedStatement.java
 	jdbc/org/postgresql/jdbc1/Jdbc1Statement.java
 	jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java
 	jdbc/org/postgresql/jdbc2/Jdbc2CallableStatement.java
 	jdbc/org/postgresql/jdbc2/Jdbc2PreparedStatement.java
 	jdbc/org/postgresql/jdbc2/Jdbc2Statement.java
 	jdbc/org/postgresql/jdbc3/Jdbc3CallableStatement.java
 	jdbc/org/postgresql/jdbc3/Jdbc3PreparedStatement.java
 	jdbc/org/postgresql/jdbc3/Jdbc3Statement.java
 Added Files:
 	jdbc/org/postgresql/PGRefCursorResultSet.java
 	jdbc/org/postgresql/jdbc1/Jdbc1RefCursorResultSet.java
 	jdbc/org/postgresql/jdbc2/Jdbc2RefCursorResultSet.java
 	jdbc/org/postgresql/jdbc3/Jdbc3RefCursorResultSet.java
 	jdbc/org/postgresql/test/jdbc2/RefCursorTest.java

Dump/read non-default GUC values for use by exec'ed backend, for Win32.

Both plannable queries and utility commands are now always executed
within Portals, which have been revamped so that they can handle the
load (they used to be good only for single SELECT queries).  Restructure
code to push command-completion-tag selection logic out of postgres.c,
so that it won't have to be duplicated between simple and extended queries.
initdb forced due to addition of a field to Query nodes.

Without this fix, CVS tip dumps core when running the regression tests
with geqo_threshold = 2.  I would think that a similar patch might be
needed in 7.3, but cannot duplicate the failure in that branch --- so
for now, leave well enough alone.

Added an option to force ecpg to also parse files includes via '#include' and some more Informix stuff.

Thanks to Wes Sheldah for finding this one.

of extended query features in new FE/BE protocol.  TransactionCommandContext
is gone (PortalContext replaces it for some purposes), and QueryContext
has taken on a new meaning (MessageContext plays its old role).

that the types of untyped string-literal constants are deduced (ie,
when coerce_type is applied to 'em, that's what the type must be).
Remove the ancient hack of storing the input Param-types array as a
global variable, and put the info into ParseState instead.  This touches
a lot of files because of adjustment of routine parameter lists, but
it's really not a large patch.  Note: PREPARE statement still insists on
exact specification of parameter types, but that could easily be relaxed
now, if we wanted to do so.

context sloppiness, some other things.  Includes Neil's mopup patch
of 22-Apr.

than PQconnectdb.  Reimplement the former to use the same code as the
latter.  Fix documentation omissions while at it.

Linux man page for it.  This error was preventing CVS tip from accepting
remote connections.

schema that was in our search path.

declared without having to write %ROWTYPE.  If the declared type of
a variable is a composite type, it'll be taken to be a row variable
automatically.

I had inadvertently omitted it while rearranging things to support
length-counted incoming messages.  Also, change the parser's API back
to accepting a 'char *' query string instead of 'StringInfo', as the
latter wasn't buying us anything except overhead.  (I think when I put
it in I had some notion of making the parser API 8-bit-clean, but
seeing that flex depends on null-terminated input, that's not really
ever gonna happen.)

test in there...

in all cases, leaked TopMemoryContext memory in others.  Make the
interaction between SetClientEncoding and InitializeClientEncoding
cleaner and better documented.  I suspect these changes should be
back-patched into 7.3, but will wait on Tatsuo's verification.

as the correct user, not only query execution.  Per report from Sean
Chittenden.

for tableID/columnID in RowDescription.  (The latter isn't really
implemented yet though --- the backend always sends zeroes, and libpq
just throws away the data.)

new stats collector oftener than once a minute.  Per gripe from Erik Walthinsen
4/25/03.

initial values and runtime changes in selected parameters.  This gets
rid of the need for an initial 'select pg_client_encoding()' query in
libpq, bringing us back to one message transmitted in each direction
for a standard connection startup.  To allow server version to be sent
using the same GUC mechanism that handles other parameters, invent the
concept of a never-settable GUC parameter: you can 'show server_version'
but it's not settable by any GUC input source.  Create 'lc_collate' and
'lc_ctype' never-settable parameters so that people can find out these
settings without need for pg_controldata.  (These side ideas were all
discussed some time ago in pgsql-hackers, but not yet implemented.)