inserting a materialize node above an inner-side sort node, when the sort is
expected to spill to disk.  (The materialize protects the sort from having
to support mark/restore, allowing it to do its final merge pass on-the-fly.)
We neglected to teach cost_mergejoin about that hack, so it was failing to
include the materialize's costs in the estimated cost of the mergejoin.
The materialize's costs are generally going to be pretty negligible in
comparison to the sort's, so this is only a small error and probably not
worth back-patching; but it's still wrong.

In the similar case where a materialize is inserted to protect an inner-side
node that can't do mark/restore at all, it's still true that the materialize
should not spill to disk, and so we should cost it cheaply rather than
expensively.

Noted while thinking about a question from Tom Raney.

David Wheeler

Add missing descriptions for aggregates, functions and conversions.

Bernd Helmle

chapter.

Author: Michelle Caisse <Michelle.Caisse@Sun.COM>

to initializaion of scanEntry.

exactly what they are in the complaint message.  Marko Kreen,
some editorialization by me.

during parsing.  Formerly the parser's stack was allocated with malloc
and so wouldn't be reclaimed; this patch makes it use palloc instead,
so that flushing the current context will reclaim the memory.  Per
Marko Kreen.

whenever possible, as per bug report from Oleg Serov.  While at it, reorder
the operations in the RECORD case to avoid possible palloc failure while the
variable update is only partly complete.

Back-patch as far as 8.1.  Although the code of the particular function is
similar in 8.0, 8.0's support for composite fields in rows is sufficiently
broken elsewhere that it doesn't seem worth fixing this.

output that is seen when a checkpoint occurs at just the right time during
the test.  Per my report of 2008-08-31.

This could be back-patched but I'm not sure it's worth the trouble.

There are still some weak spots around JOIN USING and relation alias lists,
but most errors reported within backend/parser/ now have locations.

command id is the cmin, when it can in fact be a combo cid. That made rows
incorrectly invisible to a transaction where a tuple was deleted by multiple
aborted subtransactions.

Report and patch Karl Schnaitter. Back-patch to 8.3, where combo cids was
introduced.

somewhat by adding CFLAGS where the compiler is used and Makefile.shlib
already used CFLAGS.

Per buildfarm results.

SELECT foo.*) so that it cannot be confused with a quoted identifier "*".
Instead create a separate node type A_Star to represent this notation.
Per pgsql-hackers discussion of 2007-Sep-27.

syntax to avoid a useless store into a global variable.  Per experimentation,
this works better than my original thought of trying to push the code into
an out-of-line subroutine.

David Gould

clear to me why I'd not seen this message before --- on F-9 it seems to
only happen if Asserts are disabled, which ought to be irrelevant.
Maybe that affects a decision whether to inline get_ten(), which would
be needed to expose the warning condition to the compiler?  Anyway,
the fix is clear.

change build system to use only Bison.  Simplify build rules, make file names
uniform.  Don't build the token table header file where it is not needed.

most node types used in expression trees (both before and after parse
analysis).  This allows us to place an error cursor in many situations
where we formerly could not, because the information wasn't available
beyond the very first level of parse analysis.  There's a fair amount
of work still to be done to persuade individual ereport() calls to actually
include an error location, but this gets the initdb-forcing part of the
work out of the way; and the situation is already markedly better than
before for complaints about unimplementable implicit casts, such as
CASE and UNION constructs with incompatible alternative data types.
Per my proposal of a few days ago.

when its input is constant and the element coercion function is immutable
(or nonexistent, ie, binary-coercible case).  This is an oversight in the
8.3 implementation of ArrayCoerceExpr, and its result is that certain cases
involving IN or NOT IN with constants don't get optimized as they should be.
Per experimentation with an example from Ow Mun Heng.

Fix pg_dump docs to acknowledge that you can use -Z with plain text output.  Pointed out by Daniel Migowski.

warnings.  Peter did this for core awhile ago but evidently missed
contrib.

into nodes/nodeFuncs, so as to reduce wanton cross-subsystem #includes inside
the backend.  There's probably more that should be done along this line,
but this is a start anyway.

checks in ExecIndexBuildScanKeys() that were inadequate anyway: it's better
to verify the correct varno on an expected index key, not just reject OUTER
and INNER.

This makes the entire current contents of nodeFuncs.c dead code.  I'll be
replacing it with some other stuff later, as per recent proposal.

the window during which backends have no statistics file to read.

Devrim Gunduz.

"outage" of the statistics views.

This requires making the stats collector respond to SIGHUP, like the other
utility processes already did.

it possible to call them without specifying a column list.

Jaime Casanova

Bernd Helmle

at once and ItemPointers are collected in memory.

Remove tuple's killing by killtuple() if tuple was moved to another
page - it could produce unaceptable overhead.

Backpatch up to 8.1 because the bug was introduced by GiST's concurrency support.

Simon Riggs

1. -i option should run vacuum analyze only on pgbench tables, not *all*
tables in database.

2. pre-run cleanup step was DELETE FROM HISTORY then VACUUM HISTORY.
This is just a slow version of TRUNCATE HISTORY.

Simon Riggs