- Some minor additions to Statement to make our own extensions more
          portable.
        - Statement.close() will now call ResultSet.close() rather than just
          dissasociating with it.

        - Fixed bug where Statement.setMaxRows() was a global setting. Now
          limited to just itself.
        - Changed LargeObject.read(byte[],int,int) to return the actual number
          of bytes read (used to be void).
        - LargeObject now supports InputStream's!
        - PreparedStatement.setBinaryStream() now works!
        - ResultSet.getBinaryStream() now returns an InputStream that doesn't
          copy the blob into memory first!
        - Connection.isClosed() now tests to see if the connection is still alive
          rather than if it thinks it's alive.

Need in one more function to handle "my bits moved..."
case. FixBTree is still FALSE.

update configure to beta4

Install a ChangeLog file from beta3->beta4

allocated by plan nodes are not leaked at end of query.  This doesn't
really matter for normal queries, but it sure does for queries invoked
repetitively inside SQL functions.  Clean up some other grotty code
associated with tupdescs, and fix a few other memory leaks exposed by
tests with simple SQL functions.

Robert E. Bruccole

Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates.

and two 'win32.mak'. Addresses the following:

1) Oops. Spelled fcntl.h wrong in the last one. D'uh.
2) PG_VERSION changed to be defined with " around it. psql/command.c failed
to compile without that.
3) Changed makefiles to use "/MD" and link both psql and libpq.dll against
MSVCRT.DLL instead of a static library. This takes care of the
crash-upon-free in psql.

I *think* this is what is on the "Open 7.1 Items" list as "Magnus Hagander
ODBC Issues?". It has nothing to do with ODBC, but it's the only issue I've
been involved with...

Magnus Hagander

table.

triggers ... oops ... but the regress tests should have covered this ...

(sql490.htm), there is

"set of all k-tuples v1, v2, ... vk, such that v1 [isin] D1, v1 [isin] D1"

i assume it should be
"set of all k-tuples v1, v2, ... vk, such that v1 [isin] D1, v2 [isin] D2"

Divide by Zero

not happen anyway, but let's try not to get completely confused if it does
(due to rewriter bugs or whatever).