family functions. Contain:

  conversion from a datetype to formatted text:

	to_char( datetime, 	text)
	to_char( timestamp,	text)
	to_char( int4,		text)
	to_char( int8,		text)
	to_char( float4,	text)
	to_char( float8,	text)
	to_char( numeric,	text)

  vice versa:

	to_date		( text, text)
	to_datetime	( text, text)
	to_timestamp	( text, text)
	to_number	( text, text)	   (convert to numeric)


  PostgreSQL to_char is very compatible with Oracle's to_char(), but not
total exactly (now). Small differentions are in number formating. It will
fix in next to_char() version.


! If will this patch aplly to the main tree, must be delete the current
  to_char version in contrib (directory "dateformat" and note in contrib's
  README), this patch not erase it (sorry Bruce).



The patch patching files:

	doc/src/sgml/func.sgml
                     ^^^^^^^^
   Hmm, I'm not sure if my English... :( Check it anyone (volunteer)?

   Thomas, it is right? SGML is not my primary lang  and compile
   the current PG docs tree is very happy job (hard variables setting in
   docs/sgml/Makefile --> HSTYLE= /home/users/t/thomas/....  :-)

   What add any definition to global configure.in and set Makefiles in docs
   tree via ./configure?

	src/backend/utils/adt/Makefile
	src/backend/utils/adt/formatting.c
	src/include/catalog/pg_proc.h
	src/include/utils/formatting.h
Karel Zak <zakkr@zf.jcu.cz>              http://home.zf.jcu.cz/~zakkr/

(EUC_CN does have only code set 0 and 1)

in front of any platform name pattern that's not supposed to match
beginning at the start of the machine type name...

Made type equivalency apply to aggregates (TODO item)
Fixed parsing bug in psql
Reverted some stupid options changes I made to pg_dump

(ie, WHERE x > lowbound AND x < highbound).  It's not very bright yet
but it does something useful.  Also, rename intltsel/intgtsel to
scalarltsel/scalargtsel to reflect usage better.  Extend convert_to_scalar
to do something a little bit useful with string data types.  Still need
to make it do something with date/time datatypes, but I'll wait for
Thomas's datetime unification dust to settle first.  Eventually the
routine ought not have any type-specific knowledge at all; it ought to
be calling a type-dependent routine found via a pg_type column; but
that's a task for another day.

optimizer.

Executable file name (postmaster) no more included in the file.

Since --with-mb has been removed from configure, previous
messages were not appropriate.

the charcter including trailing blanks.

an attribute of a tuple previously fetched with SearchSysCacheTuple.
This avoids a lot of redundant cache lookups, particularly in selfuncs.c.
Also, remove SearchSysCacheStruct, which was unused and grotty.

selectivity estimation wasn't right.  This is better...

updated date/time types doc
fixed small psql bug
removed libpq code that lower-cased db names
make notice when long identifier is truncated

pghackers discussion of 5-Jan-2000.  The amopselect and amopnpages
estimators are gone, and in their place is a per-AM amcostestimate
procedure (linked to from pg_am, not pg_amop).

longer in expected location).

have the rl_completion_append_character variable.  The tab completion
behavior doesn't seem to be quite perfect in that situation, but it's
better than failing to build at all...

does not end with a newline.  I don't think this explains the recent
complaints, since this bug existed in 6.5 (and probably long before).
But might as well fix it now that I see it.

New INSTALL file
Fixed a copyright notice

fact the same, so I suggest they could be the same file say
geometry-positive-zeros.out, as the main difference seems to be not printing
eg. (0,-0). In src/test/regress/expected, I propose

rm int2-i386-netbsd.out int4-i386-netbsd.out
mv geometry-hppa1.1.out geometry-positive-zeros.out
rm geometry-hppa2.0.out geometry-i386-netbsd.out

and the following patch to resultmap. I have only tested the netbsd results
on i386, but think that in all probability the differences will be the same
for other ports. If it turns out not to be the case, at least we might find
out.

Patrick Welche