destination in plpgsql.

bpchar, bit, numeric with typmod -1.  Alter format_type so that this
representation is printed when the typmod is -1.  This ensures that
tables having such columns can be pg_dump'd and reloaded correctly.
Also, remove the rather useless and non-SQL-compliant default
precision and scale for type NUMERIC.  A numeric column declared as
such (with no precision/scale) will now have typmod -1 which means
that numeric values of any precision/scale can be stored in it,
without conversion to a uniform scale.  This seems significantly
more useful than the former behavior.  Part of response to bug #513.

use that typmod not -1 as the typmod of the CASE result.
Part of response to bug#513.

typmod of a particular column, mark the output with that same typmod,
not -1 as formerly.  -1 is still used if there is any disagreement.
Part of response to bug#513.

fixed bug in ResultSet.  Version 1.29 backed out two previous fixes (1.26 and 1.25).  This checkin add back those two previous fixes.  Problem reported by Daniel Germain

Commit to support MD5 passwords as per the backend for 7.2.  This patch was submitted by Jeremy Wohl jeremyw-pgjdbc@igmus.org

andrea gelmini

index scan.  Problem was that link to outer tuple wasn't being stored
everyplace it needed to be.

operators.  Should report the declared oprresult type, not the return type
of the underlying proc, which might be only binary-compatible (cf.
textcat entries).

used inside fk constraints, since some of the checks
in the trigger did a SELECT oid.  Since the oid wasn't
actually used, I changed this to SELECT 1.  My test
case with non-oid tables now works and fk regression
appears to run fine on my machine.

Stephan Szabo

postmaster log with elog(DEBUG) so that they will be timestamped etc.
Once upon a time I think elog() was unsafe here, but it shouldn't be anymore.

Brent Verner, with review and kibitzing from Tom Lane.

to apply the proper Datum conversion macros to search key values.

Per report from Bernd Tegge, 10-Nov-01.

clauses per path key.  Indeed, we *must* do so or we will be unable to
form a valid plan for FULL JOIN with overlapping join conditions, eg
select * from a full join b on
a.v1 = b.v1 and a.v2 = b.v2 and a.v1 = b.v2.

Denis A Ustimenko

mergeclauses in RIGHT/FULL join cases, just like the other routines have.
I'm not quite sure why I thought it didn't need one --- but Nick
Fankhauser's recent bug report proves that it does.