From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values |
Date: | 2023-02-24 16:53:45 |
Message-ID: | 847247.1677257625@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-02-24 17:26:06 | Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash |
Previous Message | Alexander Lakhin | 2023-02-24 16:00:00 | Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and switching cache->snapshot |