testing purposes.

Keep SRA copyright on file because it contains BSD license clause.

yet, but they're there.  Also some editorial work on CREATE TYPE reference
page.

as speaking the one true 3.0 protocol.

handle multiple 'formats' for data I/O.  Restructure CommandDest and
DestReceiver stuff one more time (it's finally starting to look a bit
clean though).  Code now matches latest 3.0 protocol document as far
as message formats go --- but there is no support for binary I/O yet.

Allow backends to attached to specified shared memory address.

terminating zero byte in StartupMessage, docs didn't mention it.

external representation of binary data.

first version of the 3.0 protocol that can be considered non-draft.

than WIN32.

the connection when appropriate.
This checkin also adds the type map for jdbc3, however currently it is
identical to the jdbc2 mapping.

 Modified Files:
 	jdbc/org/postgresql/core/BaseStatement.java
 	jdbc/org/postgresql/core/QueryExecutor.java
 	jdbc/org/postgresql/jdbc3/AbstractJdbc3Connection.java

fork/exec.

of Describe on a prepared statement.  This was in the original 3.0
protocol proposal, but I took it out for reasons that seemed good at
the time.  Put it back per yesterday's pghackers discussion.

Describe would claim that no tuples will be returned.  Only affects
SELECTs added to non-SELECT base queries by rewrite rules.  If you
want to see the output of such a select, you gotta use 'simple Query'
protocol.

DestReceiver pointers instead of just CommandDest values.  The DestReceiver
is made at the point where the destination is selected, rather than
deep inside the executor.  This cleans up the original kluge implementation
of tstoreReceiver.c, and makes it easy to support retrieving results
from utility statements inside portals.  Thus, you can now do fun things
like Bind and Execute a FETCH or EXPLAIN command, and it'll all work
as expected (e.g., you can Describe the portal, or use Execute's count
parameter to suspend the output partway through).  Implementation involves
stuffing the utility command's output into a Tuplestore, which would be
kind of annoying for huge output sets, but should be quite acceptable
for typical uses of utility commands.

Reorder non-default variable loading until PGDATA is defined.

the column by table OID and column number, if it's a simple column
reference.  Along the way, get rid of reskey/reskeyop fields in Resdoms.
Turns out that representation was not convenient for either the planner
or the executor; we can make the planner deliver exactly what the
executor wants with no more effort.
initdb forced due to change in stored rule representation.

which does the same thing.  Perhaps at one time there was a reason to
allow plan nodes to store their result types in different places, but
AFAICT that's been unnecessary for a good while.

avoids 'input buffer overflow' failure on long literals, improves
performance, gives the right answer for line position in functions
containing multiline literals, suppresses annoying compiler warnings,
and generally is so much better I wonder why we didn't do it before.

discussion.

*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