Re: Bogus rte->relkind for EXCLUDED pseudo-relation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bogus rte->relkind for EXCLUDED pseudo-relation
Date
Msg-id 2137182.1670017626@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bogus rte->relkind for EXCLUDED pseudo-relation  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2022-12-02 12:34:36 -0500, Tom Lane wrote:
>> I find that
>> (1) ON CONFLICT's EXCLUDED pseudo-relation is assigned
>> rte->relkind = RELKIND_COMPOSITE, a rather horrid hack
>> installed by commit ad2278379.

> Is it that horrid?

It's pretty bad IMO.  You didn't even bother to update the comments
for RangeTblEntry to explain that

    char        relkind;        /* relation kind (see pg_class.relkind) */

might now not be the rel's relkind at all.  Changing RTEKind
would likely be a better way, though of course we couldn't
do that in back branches.

And I think that we do have an issue in the back branches.
According to the commit message for ad2278379,

    4) References to EXCLUDED were rewritten by the RLS machinery, as
       EXCLUDED was treated as if it were the underlying relation.

That rewriting would be post-rule-load, so it sure seems to me
that a rule containing EXCLUDED would be improperly subject to
RLS rewriting.  I don't have enough familiarity with RLS to come
up with a test case, and I don't see any relevant examples in
the mailing list threads referenced by ad2278379, but I bet
that it is broken.

The back-branch fix could just be to teach rewriteHandler.c
to not overwrite RELKIND_COMPOSITE_TYPE, perhaps.  We can't
remove the update completely because of the table-to-view case.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Fwd: Perform streaming logical transactions by background workers and parallel apply
Next
From: Peter Smith
Date:
Subject: Fwd: Perform streaming logical transactions by background workers and parallel apply