<   from making invalid dates valid?
>   from making invalid dates valid

just a preformatted message; per suggestion by Sean Chittenden.

Solaris with Open SSL version 0.9.7b

> * Exit postmaster if postgresql.conf can not be opened

	* Allow SSL-enabled clients to turn off SSL transfers

> * Change CVS $Id$ to $PostgreSQL$

specific hash functions used by hash indexes, rather than the old
not-datatype-aware ComputeHashFunc routine.  This makes it safe to do
hash joining on several datatypes that previously couldn't use hashing.
The sets of datatypes that are hash indexable and hash joinable are now
exactly the same, whereas before each had some that weren't in the other.

reasonable.

out of mind, because it'd been commented out years ago).  Try to bring the
remains up to a reasonable level of currency, and give it all approximately
the same high level of abstraction.

<   from making invalid dates valid
>   from making invalid dates valid?

> * Allow current datestyle to restrict dates;  prevent month/day swapping
>   from making invalid dates valid
> * Prevent month/day swapping of ISO dates to make invalid dates valid

regression test diffs...).

client applications.  Some editorial work on libpq.sgml, too.

a ReadyForQuery (Z message) immediately and then another one after the
Sync message arrives.  Suppress the first one to make it work per spec.

and probably other stuff.

character in identifiers.  The first change eliminates the current need
to put spaces around parameter references, as in "x<=$2".  The second
change improves compatibility with Oracle and some other RDBMSes.  This
was discussed and agreed to back in January, but did not get done.

match the SQL standard.  Document FLOAT and FLOAT(p) notations in
datatype.sgml.  Per recent pghackers discussion.

siblings.

work at all, and neither case behaved sanely for negative intervals.

silently resolving them to type TEXT.  This is comparable to what we
do when faced with UNKNOWN in CASE, UNION, and other contexts.  It gets
rid of this and related annoyances:
	select distinct f1, '' from int4_tbl;
	ERROR:  Unable to identify an ordering operator '<' for type unknown
This was discussed many moons ago, but no one got round to fixing it.

some cases of redundant clauses that were formerly not caught.  We have
to special-case this because the clauses involved never get attached to
the same join restrictlist and so the existing logic does not notice
that they are redundant.