refer to the single-byte char type.  7.0 was taking it as bpchar(1).

It worked, because they both have fields named 'data', but it's surely
trouble waiting to happen.  I wonder whether there are more ...

it's a good idea to choose the directory size based on the expected
number of entries.  But ShmemInitHash was using a hard-wired constant.
Boo hiss.  This accounts for recent report of postmaster failure when
asking for 64K or more buffers.

defaulted the opclass.  This addresses TODO item
* Allow creation of functional indexes to use default types
(Does that make it a feature?  Oh dear...)

from previous release.

platform (psql and libpq):

The file "config.h.win32" in the include\ directory (from my patch from
2000-01-18) is missing from the tree. It needs to be put back :-)

The following patch has to be applied in the interfaces\libpq directory.


//Magnus

thinks the connection is idle, the error message is displayed as if
it were a NOTICE.  This seems better than dropping the message on
the floor ... particularly if the message is the backend telling us
why it's about to close the connection.  The previous behavior was
Backend message type 0x45 arrived while idle
pqReadData() -- backend closed the channel unexpectedly.
which is not real helpful.

as a unary minus operator for numeric.  Now that long numeric constants
will get converted to NUMERIC in early parsing, it's essential to have
numeric->int8 conversion to avoid 'can't convert' errors on undecorated
int8 constants.  Threw in the rest for completeness while I was in the
area.
I did not force an initdb for this, since the system will still run
without the new pg_proc/pg_operator entries.  Possibly I should've.

and produce either FLOAT8 or NUMERIC output depending on whether the
value fits in a float8 or not.  This is almost back to the way the
code was before I changed T_Float, but there is a critical difference:
now, when a numeric constant doesn't fit in float8, it will be treated
as type NUMERIC instead of type UNKNOWN.

2. Regression tests fail for types int2 and int4 (which can easily be
fixed by adding entries to resultmap) aswell as float8 and geometry,
where floating point numbers appear to be rounded a little differently
than in your expected results (besides that I also need the positive
zeros file). I'm including a patch for the first 2, but I don't know
whether the latter two are actually a bug in postgres or a bug in the
OS or even allowed difference. I'm including my results for reference.

Rolf Grossmann

tests for the Foreign Key support in 7.0 which
was made against a CVS copy from this
afternoon.

This modifies
 src/test/regress/sql/run_check.tests
 src/test/regress/sql/alter_table.sql
 src/test/regress/expected/alter_table.out
 src/test/regress/sql/foreign_key.sql
 src/test/regress/expected/foreign_key.out

sszabo@bigpanda.co

failed to negate a negative value back to positive, so '- - 123.45'
did the wrong thing.

Thomas gets back, but better this than nonfunctional pg_dump in the beta.

integers) to be strings instead of 'double'.  We convert from string form
to internal representation only after type resolution has determined the
correct type for the constant.  This eliminates loss-of-precision worries
and gets rid of the change in behavior seen at 17 digits with the
previous kluge.

test output as expected output.  We'll probably want to change this again
after something's done about the verbosity of column alias display.

Jan

performance in catcache lookups.

* Allow PQrequestCancel() to terminate when in waiting-for-lock state
Changes are limited to BACKEND,however.

	1) freeing null pointer
	2) invalid encoding info may be stored into psql variable
	3) fix indentation