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....@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
binLPTyx5cE7r.bin
Description: lateral-2.patch.gz
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
