Re: WIP patch for LATERAL subqueries

Here's an updated version of my LATERAL patch.

* Accepts "LATERAL func_name(args)".

* Handles LATERAL in JOIN nests now. I rewrote the way
transformFromClause manages visibility of previously-parsed FROM items.
Rather than my previous idea of adding more namespace lists to a
ParseState, I changed p_relnamespace and p_varnamespace to be lists of
ParseNamespaceItem structs, which carry an RTE pointer plus visibility
flags. This seemed to work out fairly well, and allowed me to implement
the RIGHT/FULL JOIN case exactly as per SQL spec, that is the left side
of a "RIGHT JOIN LATERAL" is visible to the right side but throws error
if used. (I'm a bit tempted now to collapse p_relnamespace and
p_varnamespace into just one list, by adding two more booleans to
ParseNamespaceItem to show whether the item is visible for qualified or
unqualified references. But that would affect code that the current
patch doesn't need to touch, so it seems better to postpone it to a
separate refactoring patch.) This results in some changes in the error
messages output for improper-column-reference errors, as shown in the
regression test deltas. It also fixes the pre-existing spec-conformance
issue about lateral versus parent references, as per Andrew Gierth in
http://archives.postgresql.org/message-id/87ocpjscpa.fsf@news-spur.riddles.org.uk

* Throws error if LATERAL is used to create an aggregate that belongs to
its aggregation query's FROM clause. I did this in a slightly grotty
way: transformAggregateCall looks at the p_lateral_active field of the
appropriate pstate level, relying on the fact that the only way the
case can happen is via LATERAL. As I mentioned earlier, I think it'd
be better to add a ParseState field showing exactly which query part
we're parsing at any instant. However, again that seems better done as
part of a separate refactoring patch.

I have not done anything yet about the planner shortcomings.

What I'd like to do next, barring objections, is to band-aid the places
where the planner could crash on a LATERAL query (probably just make it
throw FEATURE_NOT_SUPPORTED errors), write some documentation, and
then commit what I've got. After that I can go back to improve the
planner and work on the parser refactoring issues as separate patches.

Comments, better ideas?

regards, tom lane