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

compliance.  Wish they were all that easy...

postgres's choice of compiler options.  Tres uncool.

followed by 'extern void foo() { ... }'.

equivalent now, which should make Windows and Mac clients happier.
Also fix failure to handle SQL comments between segments of a multiline
quoted literal.

for 'const' qualifiers yet ...

but this is as good as it'll get for this release...

appropriate btree three-way comparison routine.  Not clear why the
three-way comparison routines were being used in some paths and not
others in btree --- incomplete changes by someone long ago, maybe?
Anyway, this makes for a nice speedup in CREATE INDEX.

autoconf mailing list. ;)

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

new datetime regress test.  Someone needs to deal with fixing
expected/horology-solaris-1947.out too, assuming we still need it.