Experimental JDBC driver

Hello,

I last time added some features to JDBC driver meking in some way experimental
driver, it could be quite usefull, but if it's possible I would like to ask
for some reviews and tests. Maybe some ideas from this will be handly.
Beacause the chageset is huge, I don't give patch set, but only URL where You
can find sources and compiled binary
http://www.rsmogura.net/pgsql/

(drivers are called pgjdbc_exp).

Below is some info about changes, in TODO and TO_THINK is set of free ideas
about this.

=== JDBC 4 Exceptions ===
1. Driver can throw JDBC 4 exceptions.
2. The PSQLException is now interface, to keep as far as possible backward
compatibility, read TO_THINK
3. TODO: In many static methods still exists
PgSqlExceptionFactory.getDefault()
this should be removed.
4. TODO: Add functionality to allow user to choose between throwin
PSQL*Exceptions, or plain SQL*Exception.
5. TODO: Check if decision block about exception type is "fully" proper and
there is no missign states, eventualy try to decide to throw Trnasient / Non
Transient exceptions.
6. Currently we throw only Non Transient exception, as any error in server
only allows to commit or rollback transaction, non future data read or update
is possible.
7. TO_THINK: Change PSQLException to interface should make no differences when
client application will be fully rebuilded, but if we have some 3rd party
binary library its execution can be break (different VM opcode for calling
methods). Because we have exception factory we can
revoke PSQLException to class, create PSQLExceptionInterface and add
additional connection parameter
useOldException default true - if true then PSQLException will be thrown on
error, false SQLException implementing PSQLExceptionInterface.

=== Binary Read and Write ===
Thanks to Mikko for some concepts from his patch (especialy about integer/float
dates).
1.Few basic data types has been written (with server types)
- read: bool, double, int, short, decimal, varchar, text; date, timestamp
(with / without time zone)
- write: int, decimal, date, timestamp
- casting from server type to Java type is currently supported for few
classes and types, need to check this step by step with JDBC spec
- dates / times are limited to integer dates server, currently
2.The reader / writer is configured by connection basis with factories so if in
future PostgreSQL will change the binary representation only the appropriate
reader / writer implementation will change.
3. TODO: Use simillar to binary factory machanism to read / write character
protocol.
4. TODO: Add binary modes for PGType classes.
5. TODO: Coopy all statics converters form PGType to factory, and mark methods
as deprecated (statics disallow to use custom exception factories).
5a. Subtask create casting facility extracting PGTypes cast methods to this
facility, connect it with current if..else trees in ResultSet.get()
6. TODO: Plugability model to internal reading and writing other server types
in binary / text mode.
7. Add support for UUID Java class and server type.
8. TODO: Binary reader always return byte[], think about directly writting to
stream (less GC overhead).
9.Hack JDK MutuableInteger, less GC overhead and more preformance when parsing
DECIMAL.
10. TODO: Make additional test about timestamps (dates, etc.) with / without
time zone when server is in different timezone then driver, and what will hapen
on TZ change in client. Subject to ask on pg-hackers.
11. TO_THINK: It's good point to think about changing OID to JDBC RowId, just
sugar for sugar.
12. No describe or lazy decision to read given value as binary or character.
13. If you would like to test binary for all JUnit test call
ant -DbinaryTransfer=true

=== Other changes ===
1. setStatementTimeout - uses Java Timer. It's not fully "secure", as timer
will abort statement when statement is executing, long Java processing, or
some sub statements can break this soultion.

=== JDBC 4.1 ===
1. build.xml changes, and basic implementation (with
UnsupportedOperaionException) of some JDBC interfaces to use JDK 7 JDBC 4.1

Kind regards,
Radek