Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values
От | Tom Lane |
---|---|
Тема | Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values |
Дата | |
Msg-id | 847247.1677257625@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values
|
Список | pgsql-bugs |
Dean Rasheed <dean.a.rasheed@gmail.com> writes: > Here's an updated patch, now with test cases involving both OLD and > NEW references. It might be worth doing + if (rte->rtekind == RTE_SUBQUERY && !rte->lateral && + contain_vars_of_level((Node *) rte->subquery, 1)) + rte->lateral = true; so as to save the expense of contain_vars_of_level() when the flag is already set. However, it's arguable that no users would bother with writing LATERAL, so this might be pointless. More importantly, I think the comment could do with a bit more information. Maybe like /* + * Mark any subquery RTEs in the rule action as LATERAL if they contain + * Vars referring to the current query level (references to NEW/OLD). + * Those really are lateral references, but we've historically not + * required users to mark such subqueries with LATERAL explicitly. + * But the planner will complain if such Vars exist in a non-LATERAL + * subquery, so we have to fix things up here. + */ That might be overly verbose, but I think it's good to memorialize this sort of info. LGTM otherwise. regards, tom lane
В списке pgsql-bugs по дате отправления: