Re: UPDATE using sub selects
| От | NikhilS |
|---|---|
| Тема | Re: UPDATE using sub selects |
| Дата | |
| Msg-id | d3c4af540703300426v6e0fa69fl4dcd39d09fd74006@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: UPDATE using sub selects (NikhilS <nikkhils@gmail.com>) |
| Ответы |
Re: UPDATE using sub selects
|
| Список | pgsql-hackers |
Hi,
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
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
В списке pgsql-hackers по дате отправления: