Now indexes of pg_class and pg_type are unique indexes
and guarantee the uniqueness of correponding attributes.
heap_create() was changed to take another boolean parameter
which allows to postpone the creation of disk file.
The name of rd_nonameunlinked was changed to rd_unlinked.
It is used generally(not only for noname relations) now.
Requires initdb.

unreasonable amount of time to clean up after a vanished parser problem.
Don't call fireRIRonSubselect when we know there are no subselects,
either.

Apparently, back in the dim reaches of prehistory, the parser couldn't
be trusted to label Const nodes with the correct constbyval value ...
and someone preferred to patch around this in copyObject rather than
fix the problem at the source.  The problem is long gone, but the hack
lingered on.  Until now.

indexes to open.  Avoid unnecessary work in ExecCheckPerm, too.

make_const --- don't repeat cache searches that aren't needed.

Thanks to Hiroshi

in the TupleDesc that the caller already has (for call from ExecMain) or
can make just as easily as ExecInitJunkFilter() can (for call from
ExecAppend).  Also, don't bother to build a junk filter for an INSERT
operation that doesn't actually need one, which is the normal case.

mdnblocks.  Bad enough it does an lseek, but to do it twice for no
reason...

that has no subplan --- saves a material amount of time for a simple
INSERT ... VALUES query.

In particular, don't bother to look up type information for attributes
where we're not actually going to use it, and avoid copying entire tlist
structure when it's not necessary.

during initial run formation by keeping both current run and next-run
tuples in the same heap (yup, Knuth is smarter than I am).  And, during
merge passes, make use of available sort memory to load multiple tuples
from any one input 'tape' at a time, thereby improving locality of
access to the temp file.

never to commit without running regress tests...

before calling execProject, when the outerPlan has returned zero tuples.
I took this out under the mistaken impression that the input tuple
couldn't be referenced by execProject if we weren't in GROUP BY mode.
But it can, if we're in an UPDATE or DELETE...