casts to text.

parent query's EState.  Now that there's a single flat rangetable for both
the main plan and subplans, there's no need anymore for a separate EState,
and removing it allows cleaning up some crufty code in nodeSubplan.c and
nodeSubqueryscan.c.  Should be a tad faster too, although any difference
will probably be hard to measure.  This is the last bit of subsidiary
mop-up work from changing to a flat rangetable.

is still needed despite cleanups in setrefs.c, because the point is to
let the inserted Result node compute a different tlist than its input
node does.  Per example from Jeremy Drake.

drill down into subplan targetlists to print the referent expression for an
OUTER or INNER var in an upper plan node.  Hence, make it do that always, and
banish the old hack of showing "?columnN?" when things got too complicated.

Along the way, fix an EXPLAIN bug I introduced by suppressing subqueries from
execution-time range tables: get_name_for_var_field() assumed it could look at
rte->subquery to find out the real type of a RECORD var.  That doesn't work
anymore, but instead we can look at the input plan of the SubqueryScan plan
node.

Zdenek Kotala

Chad Wagner

and quals have varno OUTER, rather than zero, to indicate a reference to
an output of their lefttree subplan.  This is consistent with the way
that every other upper-level node type does it, and allows some simplifications
in setrefs.c and EXPLAIN.

immediately: ExecHashGetHashValue failed to restore the caller's memory
context before taking the failure exit.

useless substructure for its RangeTblEntry nodes.  (I chose to keep using the
same struct node type and just zero out the link fields for unneeded info,
rather than making a separate ExecRangeTblEntry type --- it seemed too
fragile to have two different rangetable representations.)

Along the way, put subplans into a list in the toplevel PlannedStmt node,
and have SubPlan nodes refer to them by list index instead of direct pointers.
Vadim wanted to do that years ago, but I never understood what he was on about
until now.  It makes things a *whole* lot more robust, because we can stop
worrying about duplicate processing of subplans during expression tree
traversals.  That's been a constant source of bugs, and it's finally gone.

There are some consequent simplifications yet to be made, like not using
a separate EState for subplans in the executor, but I'll tackle that later.

in the future.

function might reduce the number of free pages in the table.  Recommend
VACUUM FULL only if 20% free.

Simon Riggs.

I refactored findsplitloc and checksplitloc so that the division of
labor is more clear IMO. I pushed all the space calculation inside the
loop to checksplitloc.

I also fixed the off by 4 in free space calculation caused by
PageGetFreeSpace subtracting sizeof(ItemIdData), even though it was
harmless, because it was distracting and I felt it might come back to
bite us in the future if we change the page layout or alignments.
There's now a new function PageGetExactFreeSpace that doesn't do the
subtraction.

findsplitloc now tries the "just the new item to right page" split as
well. If people don't like the refactoring, I can write a patch to just
add that.

Heikki Linnakangas

Jun Kuwamura

and a Simplified version (China (PRC)).

Backpatch to 8.2.X.

Daojing.Zhou

Korry Douglas and Nikhil S

to have such entries, and want to be notified when we do...
Leave the plain bugfix in genbki.

Allow pltcl args to spi_prepare and plpython args to plpy.prepare to be standard type aliases as well as those known in pg_type. Similar to recent change in plperl.

      o Allow row and record variables to be set to NULL constants,
        and allow NULL tests on such variables

BLCKSZ value.

>
> * Consider decreasing the amount of memory used by PrivateRefCount
>
>   http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php
>   http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php
>

shared link line.

> * Increase locking when DROPing objects so dependent objects cannot
>   get dropped while the DROP operation is happening
>
>   http://archives.postgresql.org/pgsql-hackers/2007-01/msg00937.php

        o Allow UPDATE/DELETE WHERE CURRENT OF cursor
> 	  http://archives.postgresql.org/pgsql-hackers/2007-01/msg01014.php

>
> * Add missing operators for geometric data types
>
>   Some geometric types do not have the full suite of geometric operators,
>   e.g. box @> point
>