Hi, No. Offhand I think you'd either need to relax EXPR_SUBLINK to allow
> multiple output columns, or invent a ROW_SUBLINK SubLinkType that is > just like EXPR_SUBLINK except for allowing multiple output columns. > The latter would probably be less likely to break other things... > Yeah, was looking at EXPR_SUBLINK and its single column use case and drove to the same conclusion that inventing a new sublink type would be better too. It is indeed becoming a "not so simple and narrow fix" as you had mentioned earlier in your first response :)
I have invented a ROWEXPR_SUBLINK type that handles multiple output columns. The trouble is that since eventually columns of the parents have to be part of the query's targetList, I am sending the entire subquery as one of the entries in that list and the targetList gets populated with entries dependent on the subquery much later via make_subplan. This breaks code in rewriteTargetList (which expects every list entry to be of type TargetEntry), and expand_targetlist (which expects the targets to be present in attrno order, the entries added because of the subquery will not be in order as compared to normal "SET colname = expr" targets). Is there a simpler way of doing things? Should I try generating a resjunk TargetEntry in transformUpdateStmt and have its expr point to the subquery and see if that works? Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com
