containing a volatile function), rather than only on 'Var = Var' clauses
as before.  This makes it practical to do flatten_join_alias_vars at the
start of planning, which in turn eliminates a bunch of klugery inside the
planner to deal with alias vars.  As a free side effect, we now detect
implied equality of non-Var expressions; for example in
	SELECT ... WHERE a.x = b.y and b.y = 42
we will deduce a.x = 42 and use that as a restriction qual on a.  Also,
we can remove the restriction introduced 12/5/02 to prevent pullup of
subqueries whose targetlists contain sublinks.
Still TODO: make statistical estimation routines in selfuncs.c and costsize.c
smarter about expressions that are more complex than plain Vars.  The need
for this is considerably greater now that we have to be able to estimate
the suitability of merge and hash join techniques on such expressions.

contrib/fulltextindex/README.fti

Backpatched to 7.3.X too.

Neil Conway

for PL/PgSQL.

Neil Conway

in the documentation from that same data.

the code would only capture milliseconds where as both postgres and the java
Timestamp object support greater resolution.
Also fixed a bug reported by Rhett Sutphin where the last digit of the
fractional seconds was lost when using timestamp without time zone

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

 Modified Files:
 	jdbc/org/postgresql/jdbc2/optional/PooledConnectionImpl.java
 	jdbc/org/postgresql/test/jdbc2/optional/BaseDataSourceTest.java

Use explicit joins to avoid using the genetic query optimizer.  Also fixed
a regression test that was failing to compile.  This change also cleans up
how key names are reported as per:
A change to the value of the FK_NAME column.  Currently the returned value
is the triggers arguments which look like

"<unnamed>\000t2\000t1\000UNSPECIFIED\000a\000a\000"

This was required for server versions < 7.3 when a user did not supply
constraint names.  Every constraint was named "<unnamed>"
.  7.3 has enforced unique constraint names per table so unnamed foreign
keys will have different names "$1", "$2" and so on.  I've used logic
along the lines of the following to preserve the unique names in the
original scheme, but allow people who go to the trouble of naming their
constraints to see them:

if (triggerargs.startsWith("<unnamed>")) {
	fkname = [the whole ugly trigger args name originally used];
} else {
	fkname = [the actual fk name];
}

 Modified Files:
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
 	jdbc/org/postgresql/test/jdbc2/optional/ConnectionPoolTest.java

> 	o Allow PL/PgSQL to support array element assignment

source tree.

a qualification clause (and hence can get away with being sloppy about
distinguishing FALSE from UNKNOWN).  We need to know this in subselect.c;
marking the subplans in setrefs.c is too late.

even when cast functions are allowed to be volatile.

HAVING quals.  Normally this is an insignificant effect --- but it
will not be insignificant when these clauses contain sub-selects.
The added costs cannot affect the planning of the query containing
them, but they might have an impact when the query is a sub-query
of a larger one.

SubPlan nodes, else explaining queries containing sublinks may fail.

costs for expression evaluation, not only per-tuple cost as before.
This extension is needed in order to deal realistically with hashed or
materialized sub-selects.

ExecAssignResultTypeFromTL().

more to be done yet, but this is a good start.

supported.

direction on HP-UX; our former approach has been obsolete since HPUX 9.

Giles Lean

>
> I'd suggest that the runtime.sgml description explicitly say "values of
> at least a few thousand are recommended for production installations".

Neil Conway

Manfred Koizar