Re: Bogus rte->relkind for EXCLUDED pseudo-relation

Andres Freund <andres(at)anarazel(dot)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