avoid encroaching on the 'user' range of OIDs by allowing automatic
OID assignment to use values below 16k until we reach normal operation.

initdb not forced since this doesn't make any incompatible change;
however a lot of stuff will have different OIDs after your next initdb.

of just a relation OID, thereby not having to open the relation for itself.
This actually saves code rather than adding it for most of the existing
callers, which had the rel open already.  The main point though is to be
able to use this rather than plain addRangeTableEntry in setTargetTable,
thus saving one relation_openrv/relation_close cycle for every INSERT,
UPDATE, or DELETE.  Seems to provide a several percent win on simple
INSERTs.

On reflection, we ought to get rid of that mechanism entirely.

genbki.sh's pool (10000-16383) instead of being run-time assigned by
heap_insert.  Might as well use the pool as long as it's there ...
I was a bit bemused to realize that it hadn't been in use at all since 7.2.

initdb not forced since this doesn't really affect anything.  The OIDs
of casts and system indexes will change next time you do one, though.

and PL languages during initdb.  The default permissions for these objects
are the same as what we were assigning anyway, so there is no need to
expend space in the catalogs on them.  The space cost is particularly
significant in pg_proc's indexes, which are bloated by about a factor of 2
by the full-table update, and can never really recover the space.
initdb not forced, since the change has no actual impact on behavior.

from index, since the aggregates ignore NULLs.

be supported for all datatypes.  Add CREATE AGGREGATE and pg_dump support
too.  Add specialized min/max aggregates for bpchar, instead of depending
on text's min/max, because otherwise the possible use of bpchar indexes
cannot be recognized.
initdb forced because of catalog changes.

into indexscans on matching indexes.  For the moment, it only handles
int4 and text datatypes; next step is to add a column to pg_aggregate
so that all MIN/MAX aggregates can be handled.  Per my recent proposal.

deferred triggers: either one can create more work for the other,
so we have to loop till it's all gone.  Per example from andrew@supernews.
Add a regression test to help spot trouble in this area in future.

while completing execution of the cursor's query.  Otherwise we get wrong
answers or even crashes from non-volatile functions called by the query.
Per report from andrew@supernews.

that is a plain NULL and not a COALESCE with no inputs.  Fixes crash
reported by Michael Williamson.

decides whether to use hashed grouping instead of sort-plus-uniq
grouping. The function needs an annoyingly large number of parameters,
but this still seems like a win for legibility, since it removes over
a hundred lines from grouping_planner (which is still too big :-().

into the wrong memory context, resulting in a query-lifespan memory leak.
Bug is new in 8.0, I believe.  Per report from Rae Stiening.

< * Allow additional tables to be specified in DELETE for joins
> * -Allow additional tables to be specified in DELETE for joins

we can put words in ulink and the URL will still be printed.

per Peter

it must occur *before* we get into the critical state of holding a
lock we have no place to record.  Per discussion with Qingqing Zhou.

the held_lwlocks[] array.  Per Qingqing Zhou.

the long-term plan for this behavior for quite some time, but it is only
possible now that DELETE has a USING clause so that the user can join
other tables in a DELETE statement without relying on this behavior.

forking the stats collector child process.

end of file.

output parameters or VOID or a set.  There seems no particular reason to
insist on a RETURN in these cases, since the function return value is
determined by other elements anyway.  Per recent discussion.

updated the expected/ output, not the output/ output. Apologies.

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