Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values

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

In response to

Responses

Browse pgsql-bugs by date

  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