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

of LIMIT, and fix a few other glitches too.

portion of the query result that will be retrieved.  As far as I could
tell, the consensus was that we should let the planner do the best it
can with a LIMIT query, and require the user to add ORDER BY if he
wants consistent results from different LIMIT values.

as representing a type coercion request in more cases than we did before.
It will work now whenever no underlying function is required, ie if the
coercion is binary-compatible or if the argument is a previously untyped
string constant.  Otherwise, you still need a real function to exist.

represent the result of a binary-compatible type coercion.  At runtime
it just evaluates its argument --- but during type resolution, exprType
will pick up the output type of the RelabelType node instead of the type
of the argument.  This solves some longstanding problems with dropped
type coercions, an example being 'select now()::abstime::int4' which
used to produce date-formatted output, not an integer, because the
coercion to int4 was dropped on the floor.

Improved psql's Ctrl-C handling
Fixed configure test for sigsetjmp that now even recognizes it if it's a macro

agg_select_candidate, which could cause them to keep more candidates
than they should and thus fail to select a single match.  I had
previously fixed the identical bug in oper_select_candidate, but
didn't realize that the same error was repeated over here.
Also, repair func_select_candidate's curious notion that it could
scribble on the input type-OID vector.  That was causing failure to
apply necessary type coercion later on, leading to malfunction of
examples such as select date('now').

a few bricks shy of a load concerning knowing all the date/time types.
This is real bad because it interferes with func_select_candidate()'s
willingness to disambiguate functions --- func_select_candidate() will
punt unless all the available choices have the same type category.
I think this whole mechanism needs redesigned, but in the meantime
this is a needed patch.

command line processing.  As it stood, a bogus PGOPTIONS value from
a client would force a database system restart.  Not bad as a denial-
of-service attack...

but it's better than no test at all...

Revised code probably accepts some silly combinations, but that's better
than not accepting valid ones.

interpret a column name as an output column alias (targetlist AS name),
ather than a real column name as it ought to.  According to the spec,
only ORDER BY should look at output column names.  I left in GROUP BY's
willingness to use an output column number ('GROUP BY 2'), even though
this is also contrary to the spec --- again, only ORDER BY is supposed
to accept that.  But there is no possible reason to want to GROUP BY
an integer constant, so keeping this old behavior won't break any
SQL-compliant queries.  DISTINCT ON will behave the same as GROUP BY.

Change numerology regress test, which depended on the incorrect
behavior.

erroneous expected output for RESET DateStyle: should be ISO now.
Fix run_check.sh so that test postmaster is started with PGDATESTYLE=ISO,
else the horology test won't pass.

variable, instead calling same code in variable.c that is used to parse
SET DATESTYLE.  Fix bug: although backend's startup datestyle had been
changed to ISO, 'RESET DATESTYLE' and 'SET DATESTYLE TO DEFAULT' didn't
know about it.  For consistency I have made the latter two reset to the
PGDATESTYLE-defined initial value, which may not be the same as the
compiled-in default of ISO.