as some additional regression tests for this an other recent changes.

 Modified Files:
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
 	jdbc/org/postgresql/test/jdbc2/DateTest.java
 	jdbc/org/postgresql/test/jdbc2/ResultSetTest.java
 	jdbc/org/postgresql/test/jdbc2/TimeTest.java
 	jdbc/org/postgresql/test/jdbc2/TimestampTest.java

difference between INSERT_IN_PROGRESS and DELETE_IN_PROGRESS for
tuples inserted and then deleted by a concurrent transaction.
Example of bug:
regression=# create table foo (f1 int);
CREATE TABLE
regression=# begin;
BEGIN
regression=# insert into foo values(1);
INSERT 195531 1
regression=# delete from foo;
DELETE 1
regression=# insert into foo values(1);
INSERT 195532 1
regression=# create unique index fooi on foo(f1);
ERROR:  could not create unique index
DETAIL:  Table contains duplicated values.

not just MAXALIGN boundaries.  This makes a noticeable difference in
the speed of transfers to and from kernel space, at least on recent
Pentiums, and might help other CPUs too.  We should look at making
this happen for local buffers and buffile.c too.  Patch from Manfred Spraul.

Per past complaints --- verified to still be a problem on OS X 10.2.6.

puts that before the .c file name.

- Added protecting defines to include files.

(as distinct from their underlying indexes).  Per bug report from
Hiroshi Saito.

Per recent discussion, this does not work because other backends can't
reliably see tuples in a temp table and so cannot run the RI checks
correctly.  Seems better to disallow this case than go back to accessing
temp tables through shared buffers.  Also, disallow FK references to
ON COMMIT DELETE ROWS tables.  We already caught this problem for normal
TRUNCATE, but the path used by ON COMMIT didn't check.

(it rejects some system header files...).  Use -no-cpp-precomp instead.
I think it is okay to change this unconditionally, but if we hear
complaints from people still using very old compilers on Darwin,
we could put in a test to see which switch the compiler likes.

reindexing system tables without ignoring system indexes, when the
other two varieties of REINDEX disallow it.  Make all three act the same,
and simplify downstream code accordingly.

signal handling.

- Synced parser.
- Allowed C variables to carry the name of prepared statements.
- Added Informix handling of datatype converion errors.

type was being reported for PREPAREs.

 Modified Files:
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
 	jdbc/org/postgresql/test/jdbc2/ServerPreparedStmtTest.java

 Modified Files:
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java

 Modified Files:
 	jdbc/org/postgresql/test/jdbc2/DatabaseMetaDataPropertiesTest.java

child tables --- all cases that will trip various sanity checks elsewhere
in the system, as well as cases that should not occur in the only intended
use of this feature, namely coping with ancient pg_dump representation
of views.  Per bug report from Chris Pizzi.

Applied patch to jdbc from Kim Ho at RedHat, fixing improper handling of empty queries under the V3 protocol

 Modified Files:
 	jdbc/org/postgresql/core/QueryExecutor.java

 Modified Files:
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java

 Modified Files:
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java

that would not get correctly looked up in the translation files for jdbc

 Modified Files:
 	jdbc/org/postgresql/errors.properties
 	jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java

in the jdbc driver

 Modified Files:
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
 	jdbc/org/postgresql/jdbc3/AbstractJdbc3Statement.java

I thought I'd fixed this earlier, but I didn't get it right ...

like 'date' in a public header file is a damn fool idea.

changed, it should allow a zero value (implying no changes to make).

really general fix might be difficult, I believe the only case where
AtCommit_Notify could see an uncommitted tuple is where the other guy
has just unlistened and not yet committed.  The best solution seems to
be to just skip updating that tuple, on the assumption that the other
guy does not want to hear about the notification anyway.  This is not
perfect --- if the other guy rolls back his unlisten instead of committing,
then he really should have gotten this notify.  But to do that, we'd have
to wait to see if he commits or not, or make UNLISTEN hold exclusive lock
on pg_listener until commit.  Either of these answers is deadlock-prone,
not to mention horrible for interactive performance.  Do it this way
for now.  (What happened to that project to do LISTEN/NOTIFY in memory
with no table, anyway?)