jdbc datasource support for jdk1.4/jdbc3

 Modified Files:
 	jdbc/build.xml jdbc/org/postgresql/Driver.java.in
 	jdbc/org/postgresql/jdbc2/optional/BaseDataSource.java
 	jdbc/org/postgresql/jdbc2/optional/PGObjectFactory.java
 	jdbc/org/postgresql/jdbc2/optional/PooledConnectionImpl.java
 	jdbc/org/postgresql/jdbc2/optional/PoolingDataSource.java
 	jdbc/org/postgresql/test/jdbc2/optional/BaseDataSourceTest.java
 	jdbc/org/postgresql/test/jdbc2/optional/OptionalTestSuite.java
 	jdbc/org/postgresql/test/jdbc3/Jdbc3TestSuite.java
 Added Files:
 	jdbc/org/postgresql/jdbc3/Jdbc3ConnectionPool.java
 	jdbc/org/postgresql/jdbc3/Jdbc3ObjectFactory.java
 	jdbc/org/postgresql/jdbc3/Jdbc3PooledConnection.java
 	jdbc/org/postgresql/jdbc3/Jdbc3PoolingDataSource.java
 	jdbc/org/postgresql/jdbc3/Jdbc3SimpleDataSource.java
 	jdbc/org/postgresql/test/jdbc2/optional/PoolingDataSourceTest.java
 	jdbc/org/postgresql/test/jdbc3/Jdbc3ConnectionPoolTest.java
 	jdbc/org/postgresql/test/jdbc3/Jdbc3PoolingDataSourceTest.java
 	jdbc/org/postgresql/test/jdbc3/Jdbc3SimpleDataSourceTest.java
 	jdbc/org/postgresql/test/util/MiniJndiContext.java
 	jdbc/org/postgresql/test/util/MiniJndiContextFactory.java

and PUBLIC EXECUTE, respectively.  Per discussion about easing updates
from prior versions.

document that scheme.

Fixes problem with cases like
SELECT * FROM foo t WHERE NOT EXISTS (SELECT remoteid FROM
(SELECT f1 as remoteid FROM foo WHERE f1 = t.f1) AS t1)

executor should not return the tuple as successfully marked, because in
fact it's been deleted.  Not clear that this case has ever been seen
in practice (I think you'd have to write a SELECT FOR UPDATE that calls
a function that deletes some row the SELECT will visit later...) but we
should be consistent.  Also add comments to several other places that
got it right but didn't explain what they were doing.

editing.

backends.  Given that temp tables now store data locally in the local
buffer manager, these things are not going to work safely.

to avoid having to write explicit casts.  From Joe Conway.

> * Add start time to pg_stat_activity

The error message said so :-)

In 25.3. Using PL/Python

        If the trigger "when" is BEFORE, you may return None or "OK"
        from the Python function to indicate the tuple is unmodified, "SKIP"
        to abort the event, or "MODIFIED" to indicate you've modified the tuple.

should read
        If the trigger "when" is BEFORE, you may return None or "OK"
        from the Python function to indicate the tuple is unmodified, "SKIP"
        to abort the event, or "MODIFY" to indicate you've modified the tuple.

elein

up to
reaching the hard limit. After opening 16(=current REST_START value)
results via pg_exec, the next pg_exec tries to find an empty slot
forever :-( . In PgSetResultId file pgtclId.c in the for loop there
has to be done a break, if res_max ist reached. The piece of code
should look like
        if (resid == connid->res_max)
        {
            resid = 0;
            break;   /* the break as to be added */
        }

now everything works (double available results after reaching
RES_START up to reaching RES_HARD_MAX)

Gerhard Hintermayer

recent bug report).  Fix processing of nailed-in-cache indexes;
it appears that REINDEX DATABASE has been broken for months :-(.

contains the correct statistics.  This is a partial solution for the
problem of allowing concurrent CREATE INDEX commands: unless they commit
at nearly the same instant, the second one will see the first one's
pg_class updates as committed, and won't try to update again, thus
avoiding the 'tuple concurrently updated' failure.

do.

versions of bison.

even when dealing with a nailed-in-cache relation; otherwise, following
VACUUM truncation of a system catalog, other backends might have
unreasonably large values of these fields.

YYERROR_VERBOSE" from contrib/cube and contrib/seg, and adjusts the expected
output accordingly. Hopefully this will consistently pass across multiple
bison versions.

Joe Conway

columns, to allow more correct behavior in multiple-inheritance cases.
Patch by Alvaro Herrera, review by Tom Lane.

the SQL99 standard.  (I'm not sure that the character-class features are
quite right, but that can be fixed later.)  Document SQL99 and POSIX
regexps as being different features; provide variants of SUBSTRING for
each.

parse analysis and into the execution code (in tablecmds.c).  This
eliminates a lot of unreasonably complex code that needed to have two
or more execution paths in case it was dealing with a not-yet-created
table column vs. an already-existing one.  The execution code is always
dealing with already-created tables and so needs only one case.  This
also eliminates some potential race conditions (the table wasn't locked
between parse analysis and execution), makes it easy to fix the gripe
about wrong referenced-column names generating a misleading error message,
and lets us easily add a dependency from the foreign-key constraint to
the unique index that it requires the referenced table to have.  (Cf.
complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.)

Also, third try at building a deletion mechanism that is not sensitive
to the order in which pg_depend entries are visited.  Adding the above-
mentioned dependency exposed the folly of what dependency.c had been
doing: it failed for cases where B depends on C while both auto-depend
on A.  Dropping A should succeed in this case, but was failing if C
happened to be visited before B.  It appears the only solution is two
separate walks over the dependency tree.

-ffast-math.

with OPAQUE.  CREATE LANGUAGE, CREATE TRIGGER, and CREATE TYPE will all
accept references to functions declared with OPAQUE --- but they will
issue a NOTICE, and will modify the function entries in pg_proc to have
the preferred type-safe argument or result types instead of OPAQUE.
Per recent pghackers discussions.