Dump/display 'timestamp' as 'timestamp with time zone', to make room for a
future 'timestamp without time zone', which SQL claims is equivalent to
plain 'timestamp'.

Move PL docs to programmer's guide, "storage" chapter to admin guide,
clean up some things in the affected areas.

Check for -lresolv.

Pass LDFLAGS along with LIBS to the Python build stuff, especially to pick
up -L options.

Must run jadetex three times to get correct page numbers.  Add support for
pdfjadetex.

When making xrefs to refsects, the linkend should point to the refsect and
the endterm to the title element, not both to the title.  At least
docbook2man prefers it that way.

Re-add Peter E's changes.

Fix inappropriate attempt to push down qual clauses into a view that
has UNION/INTERSECT/EXCEPT operations.  Per bug report from Ferrier.

Use elog() instead of exit() for fatal scanner errors.

Improved wording, from Albert REINER <areiner@tph.tuwien.ac.at>.

Update, polish, consistencify preface/intro sections.

Change description.

Runtime tree recovery is implemented, just testing is left -:)

Apply patches for QNX from Maurizio

A patch for the GROUP BY/HAVING example.  p.date should be s.date.

Robert B. Easter

    Please replace with the one attached to this email message. The
previous version depended on the below patch, this one does not. It is
also a bit cleaner and has a few more helpful comments.

Ryan Kirkpatrick

Applied two bug fixes by Christof Petig.

Wed Jan 31 08:46:00 GMT 2001 peter@retep.org.uk
        - 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.

Tue Jan 30 22:24:00 GMT 2001 peter@retep.org.uk
        - 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.

Couple additional functions to fix tree at runtime.
Need in one more function to handle "my bits moved..."
case. FixBTree is still FALSE.

Update /contrib README and add init.d from Ryan.

Update HISTORY/release with current changes.

Update TODO list.

Remove unused TODO.detail functions.

Remove subquery.

Update TODO list.

Update TODO list.

Update to PyGreSQL-3.1

Call _bt_fixroot() from _bt_insertonpg.

update configure to beta4

Install a ChangeLog file from beta3->beta4

Update FAQ.

Clean up handling of tuple descriptors so that result-tuple descriptors
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.

The following patch is required for successful compilation on Irix.

Robert E. Bruccole

Update FAQ.

Update FAQ.

Update FAQ.

Update TODO list.

Update TODO list.

Update FAQ.

Update TODO list.

Used LEFT OUTER JOIN for various queries

Applied (slightly modified) patches from Tatsuo:

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.

Here is an update on the Win32 patch. Modified files are 'config.h.win32'
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

Update FAQ.

Add 'foreign' file.

Add missing pgaccess files.

Update to pgaccess 0.98.7.

When dropping the schema, reconnect as owner of each object.

Make into appendix, correct some items.

Add permission check for CHECKPOINT.

Fix failure to create sequences for more than one SERIAL column in a
table.

Update TODO list.

Update TODO list.

Looks like I broke cases involving combinations of deferred update/delete
triggers ... oops ... but the regress tests should have covered this ...

in the tutorial, chapter 2., "Relational Data Model Formalities"
(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

Update TODO list.

Don't crash if subquery appears multiple times in jointree.  This should
not happen anyway, but let's try not to get completely confused if it does
(due to rewriter bugs or whatever).

Repair bug reported by Huxton, 1/24/01.  We need to include a rule's
original table ('OLD' table) in its join tree if OLD is referenced by
either the rule action, the rule qual, or the original query qual that
will be added to the rule action.  However, we only want one instance
of the original table to be included; so beware of the possibility that
the rule action already has a jointree entry for OLD.

Update FAQ.

Update FAQ.

    Just a quick patch to make the geometry test on Sparc/Linux
regression tests for Pgsql 7.1beta3 pass. This is very similr to the one I
submitted back in July for Linux/Alpha. Apparently non-x86 Linux machines
like to compute nth place float point digits like Sun/Solaris does?
        Otherwise, 7.1beta3 runs without problems (i.e. all other
regression tests pass) on my Sparc 20 running Debian GNU/Linux 2.2.

Ryan Kirkpatrick

Refuse to try to attach a condition to a NOTIFY or other utility statement,
rather than coredumping (as prior 7.1 code did) or silently dropping the
condition (as 7.0 did).  This is annoying but there doesn't seem to be
any good way to fix it, short of a major querytree restructuring.

Suppress coredump when EXPLAINing query that is rewritten to include
a NOTIFY.

Re-read Unix-socket lock file every so often (every CheckPoint interval,
actually) to ensure that its file access time doesn't get old enough to
tempt a /tmp directory cleaner to remove it.  Still another reason we
should never have put the sockets in /tmp in the first place ...

Clean up markup, add description of contrib/array operators by Joel Burton
<jburton@scw.org>.

Change float8-to-int8 conversion to round to nearest, rather than
truncating to integer.  Remove regress test that checks whether
4567890123456789 can be converted to float without loss; since that's
52 bits, it's on the hairy edge of failing with IEEE float8s, and indeed
rint seems to give platform-dependent results for it.

odbc1.diff changes the text on the Protocol Radio buttons on the driver
dialogue from '6.4/6.5' to '6.5+' and removes some C++ comments from
resource.h (which VC++ insists on putting there).

odbc2.diff adds code to query the PostgreSQL version upon connection. This
is then used to determine what values to return for from SQLGetInfo for
SQL_DBMS_VER, SQL_MAX_ROW_SIZE, SQL_MAX_STATEMENT_LEN, SQL_OJ_CAPABILITIES
and SQL_OUTER_JOINS. The version string as returned by SELECT vERSION() (as
a char array) and the major.minor version number (as a flost) have been
added to the ConnectionClass structure.

Dave Page

gcc complains about improperly terminated comment.

Update TODO list.

Add some links from data type chapter to section on literal constants.

Update TODO list.

Update TODO list.

Update TODO list.

Update TODO list.

Update TODO list.

Special case in ProcSleep() wasn't sufficiently general: must check to
see if we shouldn't block whenever we insert ourselves anywhere before
the end of the queue, not only at the front.

First step in attempt to fix tree at runtime: create upper levels
and new root page if old root one was splitted but new root page
wasn't created.
New code is protected by FixBTree bool flag setted to FALSE, so
nothing should be affected by this untested approach.

Synced gram.y and preproc.y.

For missing owner of database, default to superuser.

Avoid bogus failures due to 'ps x | grep postmaster' detecting 'grep
postmaster' process.

Added an alternative constructor to PGSQLException so that debugging
          some more osteric bugs is easier. If only 1 arg is supplied and it's
          of type Exception, then that Exception's stacktrace is now included.

This was done as there's been a report of an unusual bug during connection.
This will make this sort of bug hunting easier from now on.

Add to TODO.detail.

Update TODO list.

Update TODO list.

Whoops, forgot to do ProcLockWakeup() after deadlock checker
rearranges wait queues.

Add.

Re-implement deadlock detection and resolution, per design notes posted
to pghackers on 18-Jan-01.

Further to the previous ODBC patches I posted today, I found a couple of
problems with char array sizes having set a couple of constants to 0 for
unlimited query length and row length. This additional patch cleans those
problems up by defining a new constant (STD_STATEMENT_LEN) to 65536 and
using that in place of MAX_STATEMENT_LEN.

Another constant (MAX_MESSAGE_LEN) was defined as 2*BLCKSZ, but is now
65536. This is used to define the length of the message buffer in a number
of places and as I understand it (probably not that well!) therefore also
places a limit on the query length. Fixing this properly is beyond my
capabilities but 65536 should hopefully be large enough for most people.

Apologies for being over-enthusiastic and posting 3 patches in one day
rather than 1 better tested one!

Regards,

Dave Page

> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 24 January 2001 16:51
> To: Dave Page
> Subject: Re: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
>
>
> > SQL_OJ_LEFT = Left outer joins are supported.
>
> Yes.
<snip>

In addition to my earlier patch, this one adds support for SQLGetInfo
SQL_OJ_CAPABILITIES to the ODBC driver.

Dave Page

I decided to give this a go after all :-) The attached patch does the
following but it does *not* check whether the user is connected to
PostgreSQL 7.0.x or 7.1 first (as would be required for some of the
features) - the driver doesn't do this at all afaik and it's beyond my
capabilities to implement such checking in code that doesn't look like it
was written by my 1 year old daughter!

1) The driver now reports no maximum query length (SQL_MAX_QUERY_SIZE).
2) The driver now reports no maximum row length (SQL_MAX_ROW_SIZE).
3) The driver now reports that Outer Joins are supported (SQL_OUTER_JOINS),
but still does not report oj capabilities (SQL_OJ_CAPABILITIES).
4) The version number has been incremented to 7.1.0000 in psqlodbc.h *and*
psqlodbc.rc

Regards,

Dave Page

This patch fixes an arrayindexoutofbounds exception that was just
introduced into the code.  The fix is a fix to
org.postgresql.core.ByteArrayDim1.java.

Barry Lind

Add ./include/config.h.win32 to RELEASE update list.

Add to inheritance

Update TODO list.

Attached is a revised patch that removes the static SimpleDateFormat
objects that Thomas pointed out might be a problem.

PPS.  I have included and updated the comments from the original patch
request to reflect the changes made in this revised patch.

> Attached is a set of patches for a couple of bugs dealing with
> timestamps in JDBC.
>
> Bug#1) Incorrect timestamp stored in DB if client timezone different
> than DB.
> The buggy implementation of setTimestamp() in PreparedStatement simply
> used the toString() method of the java.sql.Timestamp object to convert
> to a string to send to the database.  The format of this is yyyy-MM-dd
> hh:mm:ss.SSS which doesn't include any timezone information.  Therefore
> the DB assumes its timezone since none is specified.  That is OK if the
> timezone of the client and server are the same, however if they are
> different the wrong timestamp is received by the server.  For example if
> the client is running in timezone GMT and wants to send the timestamp
> for noon to a server running in PST (GMT-8 hours), then the server will
> receive 2000-01-12 12:00:00.0 and interprete it as 2000-01-12
> 12:00:00-08 which is 2000-01-12 04:00:00 in GMT.  The fix is to send a
> format to the server that includes the timezone offset.  For simplicity
> sake the fix uses a SimpleDateFormat object with its timezone set to GMT
> so that '+00' can be used as the timezone for postgresql.  This is done
> as SimpleDateFormat doesn't support formating timezones in the way
> postgresql expects.
>
> Bug#2) Incorrect handling of partial seconds in getting timestamps from
> the DB
>
> When the SimpleDateFormat object parses a string with a format like
> yyyy-MM-dd hh:mm:ss.SS it expects the fractional seconds to be three
> decimal places (time precision in java is miliseconds = three decimal
> places).  This seems like a bug in java to me, but it is unlikely to be
> fixed anytime soon, so the postgresql code needed modification to
> support the java behaviour.  So for example a string of '2000-01-12
> 12:00:00.12-08' coming from the database was being converted to a
> timestamp object with a value of 2000-01-12 12:00:00.012GMT-08:00.  The
> fix was to check for a '.' in the string and if one is found append on
> an extra zero to the fractional seconds part.
>
>
> I also did some cleanup in ResultSet.getTimestamp().  This method has
> had multiple patches applied some of which resulted in code that was no
> longer needed.  For example the ISO timestamp format that postgresql
> uses specifies the timezone as an offset like '-08'.  Code was added at
> one point to convert the postgresql format to the java one which is
> GMT-08:00, however the old code was left around which did nothing.  So
> there was code that looked for yyyy-MM-dd hh:mm:sszzzzzzzzz and
> yyyy-MM-dd hh:mm:sszzz.  This second format would never be encountered
> because zzz (i.e. -08) would be converted into the former (also note
> that the SimpleDateFormat object treats zzzzzzzzz and zzz the same, the
> number of z's does not matter).
>
>
> There was another problem/fix mentioned on the email lists today by
> mcannon@internet.com which is also fixed by this patch:
>
> Bug#3) Fractional seconds lost when getting timestamp from the DB
> A patch by Jan Thomea handled the case of yyyy-MM-dd hh:mm:sszzzzzzzzz
> but not the fractional seconds version yyyy-MM-dd hh:mm:ss.SSzzzzzzzzz.
> The code is fixed to handle this case as well.

Barry Lind

WAL documentation, from Oliver Elphick and Vadim Mikheev.

Update based on documentation written by Vadim Mikheev and Oliver Elphick.

Change Copyright from PostgreSQL, Inc to PostgreSQL Global Development Group.

Update TODO list.

Fix bogus pattern for STRING.