in UPDATE. We also now issue a NOTICE if a query has _any_ implicit
range table entries -- in the past, we would only warn about implicit
RTEs in SELECTs with at least one explicit RTE.

As a result of the warning change, 25 of the regression tests had to
be updated. I also took the opportunity to remove some bogus whitespace
differences between some of the float4 and float8 variants. I believe
I have correctly updated all the platform-specific variants, but let
me know if that's not the case.

Original patch for DELETE ... USING from Euler Taveira de Oliveira,
reworked by Neil Conway.

functions. This patch optimizes int2_sum(), int4_sum(), float4_accum()
and float8_accum() to avoid needing to copy the transition function's
state for each input tuple of the aggregate. In an extreme case
(e.g. SELECT sum(int2_col) FROM table where table has a single column),
it improves performance by about 20%. For more complex queries or tables
with wider rows, the relative performance improvement will not be as
significant.

ExecProcNode() with a NULL value, so the test couldn't do anything
for us except maybe mask bugs.  Removing it probably doesn't save
anything much either, but then again this is a hot-spot routine.

few palloc's.  I also chose to eliminate the restype and restypmod fields
entirely, since they are redundant with information stored in the node's
contained expression; re-examining the expression at need seems simpler
and more reliable than trying to keep restype/restypmod up to date.

initdb forced due to change in contents of stored rules.

required for us to pull it into the main website. Same kind of fixes as
last time, just make sure things aren't violating the HTML standard. No
context changes at all.

Magnus Hagander

output of \dD in psql. From Greg Sabino Mullane.

braces around single statements (for PG_TRY macros).  This patch fixes
it. Alvaro Herrera.

OPENed on non-SELECT commands such as EXPLAIN or SHOW (anything that
returns tuples is allowed).  This flexibility already existed for
bound cursors, but OPEN was artificially restricting what it would
take.  Per a gripe some months back.

performance hack Tom introduced recently. This means we can avoid
copying the transition array for each input tuple if these functions
are invoked as aggregate transition functions.

To test the performance improvement, I created a 1 million row table
with a single int4 column. Without the patch, SELECT avg(col) FROM
table took about 4.2 seconds (after the data was cached); with the
patch, it took about 3.2 seconds. Naturally, the performance
improvement for a less trivial query (or a table with wider rows)
would be relatively smaller.

not the brand of vodka. Complete FETCH <sth> <sth> with FROM and IN, not
FROM and TO (which is still pretty incomplete, but at least its the right
syntax).

From Robert Treat.

comment. Patch from Alvaro.

outer side of an outer join.  Per andrew@supernews.

daemonize routine, namely forcing stdin/stdout/stderr to point
to /dev/null.  Per Karl Denninger.

cases with binary-compatible relabeling.  My first try was implicitly
assuming that all operators scalarineqsel is used for have binary-
compatible datatypes on both sides ... which is very wrong of course.
Per report from Michael Fuhr.

PL languages.

January --- would return wrong year for 2005-01-01 and 2006-01-01.

per report from Robert Creager.

Backpatch to 8.0.X.

for a function taking no arguments, per report from Michael Fuhr.

exit.  Without this, operations triggered during backend exit (such as
temp table deletions) won't be counted ... which given heavy usage of
temp tables can lead to pg_autovacuum falling way behind on the need
to vacuum pg_class and pg_attribute.  Per reports from Steve Crawford
and others.

functions with OUT parameters.  The various PLs still need work, as does
pg_dump.  Rudimentary docs and regression tests included.

2 implement gtsvector_out for use with gevel module (debug GiST indexes, http://www.sai.msu.su/~megera/postgres/gist/gevel/)

old comment in the code claimed that this was necessary. Since it is not
actually necessary any more, it is clearer to remove the comment and
just return NULL instead -- the return value of ExecHash() is not used.

Mark Kirkwood.

platforms, and suggest using ~/.pgpass instead.

proposal for OUT parameter support.  The columns don't actually *do*
anything yet, they are just left NULLs.  But I thought I'd commit this
part separately as a fairly pure example of the tasks needed when adding
a column to pg_proc or one of the other core system tables.

implement any new feature, it just pushes the 'not implemented' error
message deeper into the backend.  I also tweaked the grammar to accept
Oracle-ish parameter syntax (parameter name first), as well as the
SQL99 standard syntax (parameter mode first), since it was easy and
people will doubtless try to use both anyway.

former to 100 by default.  Clean up some of the less necessary
dependencies on FUNC_MAX_ARGS; however, the biggie (FunctionCallInfoData)
remains.