selectivity functions and make the r-tree operators use them.  The
estimation functions themselves are just stubs, unfortunately, but
perhaps someday someone will make them compute realistic estimates.
Change pg_am so that the optimizer can reliably tell the difference
between ordered and unordered indexes --- before it would think that
an r-tree index can be scanned in '<<' order, which is not right AFAIK.
Repair broken negator links for network_sup and related ops.
Initdb forced.  This might be my last initdb force for 7.0 ... hope so
anyway ...

 Transform datetime and timespan into timestamp and interval.
 Deprecate datetime and timespan, though translate to new types in gram.y.
 Transform all datetime and timespan catalog entries into new types.
 Make "INTERVAL" reserved word allowed as a column identifier in gram.y.
 Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility
  routines for all date/time types.
 date.{h,c} now deals with date, time types.
 timestamp.{h,c} now deals with timestamp, interval types.
 nabstime.{h,c} now deals with abstime, reltime, tinterval types.
Make NUMERIC a known native type for purposes of type coersion. Not tested.

accesses versus sequential accesses, a (very crude) estimate of the
effects of caching on random page accesses, and cost to evaluate WHERE-
clause expressions.  Export critical parameters for this model as SET
variables.  Also, create SET variables for the planner's enable flags
(enable_seqscan, enable_indexscan, etc) so that these can be controlled
more conveniently than via PGOPTIONS.

Planner now estimates both startup cost (cost before retrieving
first tuple) and total cost of each path, so it can optimize queries
with LIMIT on a reasonable basis by interpolating between these costs.
Same facility is a win for EXISTS(...) subqueries and some other cases.

Redesign pathkey representation to achieve a major speedup in planning
(I saw as much as 5X on a 10-way join); also minor changes in planner
to reduce memory consumption by recycling discarded Path nodes and
not constructing unnecessary lists.

Minor cleanups to display more-plausible costs in some cases in
EXPLAIN output.

Initdb forced by change in interface to index cost estimation
functions.

 Don Baccus

Jan

  * Portions Copyright (c) 1996-2000, PostgreSQL, Inc

to all files copyright Regents of Berkeley.  Man, that's a lot of files.

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/

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

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

pg_char_to_encoding()
pg_encoding_to_char()

data in its pg_proc entry.  abs() doesn't require two arguments, last
I heard.

in trigger manager.

Jan

Jan

* Document/trigger/rule so changes to pg_shadow recreate pg_pwd

I did it with a trigger and it seems to work like a charm. The function
that already updates the file for create and alter user has been made a
built-in "SQL" function and a trigger is created at initdb time.

Comments around the pg_pwd updating function seem to be worried about
this
routine being called concurrently, but I really don't see a reason to
worry about this. Verify for yourself. I guess we never had a system
trigger before, so treat this with care, and feel free to adjust the
nomenclature as well.

--
Peter Eisentraut                  Sernanders väg 10:115

comparision functions.

Added all lztext comparision functions, operators and a default
operator class for nbtree on lztext.

Jan

Jan

Now WHERE restriction on ctid is allowed though it is
sequentially scanned.

FOREIGN KEY triggers.

Added pg_proc entries for all the new functions.

Jan

Jan

Frankpitt, plus some improvements from yours truly.  The simplifier depends
on the proiscachable field of pg_proc to tell it whether a function is
safe to pre-evaluate --- things like nextval() are not, for example.
Update pg_proc.h to contain reasonable cacheability information; as of
6.5.* hardly any functions were marked cacheable.  I may have erred too
far in the other direction; see recent mail to pghackers for more info.
This update does not force an initdb, exactly, but you won't see much
benefit from the simplifier until you do one.

and 1370 (timestamp(datetime)).  This does not force an initdb, exactly,
but you won't see the effects of the bug fix until you do one.
BTW, OID 1358 for timespan(time) is still broken:
select timespan('21:11:26'::time);
ERROR:  No such function 'time_timespan' with the specified attributes
But I couldn't figure out what it ought to be defined as, so I left it be.

been applied. The patches are in the .tar.gz attachment at the end:

varchar-array.patch     this patch adds support for arrays of bpchar() and
                        varchar(), which where always missing from postgres.

                        These datatypes can be used to replace the _char4,
                        _char8, etc., which were dropped some time ago.

block-size.patch        this patch fixes many errors in the parser and other
                        program which happen with very large query statements
                        (> 8K) when using a page size larger than 8192.

                        This patch is needed if you want to submit queries
                        larger than 8K. Postgres supports tuples up to 32K
                        but you can't insert them because you can't submit
                        queries larger than 8K. My patch fixes this problem.

                        The patch also replaces all the occurrences of `8192'
                        and `1<<13' in the sources with the proper constants
                        defined in include files. You should now never find
                        8192 hardwired in C code, just to make code clearer.


--
Massimo Dal Zotto

pg_proc entries for array I/O routines besides the one detected by the
original patcher.  Tighten type_sanity regress test accordingly.

actually takes three. Please apply the following patch.

Massimo

function is found in prosrc field of pg_proc, not proname.  This allows
multiple aliases of a built-in to all be implemented as direct builtins,
without needing a level of indirection through an SQL function.  Replace
existing SQL alias functions with builtin entries accordingly.
Save a few K by not storing string names of builtin functions in fmgr's
internal table (if you really want 'em, get 'em from pg_proc...).
Update opr_sanity with a few more cross-checks.

and newly expanded opr_sanity tests.

I would like some feedback on what the hash function for the int8 hash
function
in the ./backend/access/hash/hashfunc.c should return.

Also, could someone (maybe Tomas Lockhart?) look-over the patch and make
sure
the system table entries are correct?  I've tried to research them as
much as I
could, but some of them are still not clear to me.

Thanks,
-Ryan

and pg_operator.  The lone error in pg_operator was reported as a bug
by Michael Reifenberger; the multiple errors in pg_proc would only have
been noticed if one invoked the functions by name rather than using
operator syntax.  I guess few people do that.

Fix output type for int8out, but I don't think it matters.

and aggregates.

Jan

Fix one usage of substr() which mapped to the "Oracle compatibility" funcs
 rather than the more recent (and closer to SQL92) function in varlena.c.
Add more DESC() entries for conversion functions.

Extend new type coersion techniques to aggregates.

This will fix the problem reported by Jose' Soares
 when trying to cast a float to text.