[Chicken-announce] [ANN] Postgresql egg 3.8 has been released

[Peter Bex]

Hi all,

I am pleased to announce version 3.8 of the Postgresql egg.  It should
appear as a download for chicken-install shortly.

This is really a maintenance release, but an important one.  Performance
has been improved in several key places, and a few simple benchmarks are
in the source tree now.  I've also fixed some potential bugs that might
rear their ugly heads in extreme circumstances as well as a bug which
cropped up during stress testing: a program could get stuck in an endless
loop waiting for more data to become available asynchronously when using
the put-copy-data API.

There are also two changes that deserve some attention:

The first is a breaking change: the return type of the unescape-bytea
procedure has been changed to u8vector, for consistency and correctness
reasons (escape-bytea and put-copy-data now accept any SRFI-4 vector).

The other change is in the exception handling: Errors raised by
postgresql egg procedures used to be simply (exn postgresql), with
a *lot* of informational properties hanging off the POSTGRESQL condition.
This has been tweaked to be more informative: different kinds of errors
now raise different conditions, like (exn connect postgresql) or
(exn i/o postgresql) -- see the docs for more information.
It turns out that all the extra information is only available in case
the error is caused by a problem with a query (ie, when there's a
PGresult object around in which libpq can store this information).

To avoid polluting the other exceptions with all these extra properties,
I've decided to deprecate the properties on the POSTGRESQL condition in
favor of the new QUERY condition in composite conditions of type
(exn query postgresql).  In the intermediate period I've decided to
keep around a copy of all the properties on the POSTGRESQL condition,
but everyone should check their code and change it to read them off
the QUERY condition before the deprecation period is over (this copying
behaviour will be dropped in 3.10 or 4.0, whichever comes first).
The next version will most likely also have support for the error
information that was added with PostgreSQL 9.2.  That means you'll
be able to figure out the name of the schema, table, column and
constraint which are responsible for triggering an error.

I'd love some feedback on the API, but especially on the "COPY" API.
I think it is about ready to be considered "stable", so if you have
suggestions for improvement which may break compatibility, now is a
good time to make them.

I wish everyone a happy new year!

Cheers,
Peter
-- 
http://www.more-magic.net