set-returning functions or SRF's.

for clarity.

that used to do it in planner.  That was an ancient kluge that was
never satisfactory; errors should be detected at parse time when possible.
But at the time we didn't have the support mechanism (expression_tree_walker
et al) to make it convenient to do in the parser.

simplify callers.  It turns out the common case is that the caller
does want to recurse into sub-queries, so push support for that into
these subroutines.

printed data is comparable to what you could read in the pg_locks view,
were you fortunate enough to have been looking at it at the right time.

with result that flatten_join_alias_vars failed to descend into subselects.

datetime token tables.  Even more embarrassing, the regression tests
revealed some of the problems --- but evidently the bogus output wasn't
questioned.  Add code to postmaster startup to directly check the tables
for correct ordering, in hopes of not being embarrassed like this again.

join_references(), it's practical to consolidate all join_references()
processing into the set_plan_references traversal in setrefs.c.  This
seems considerably cleaner than the old way where we did it for join
quals in createplan.c and for targetlists in setrefs.c.

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().