Andres Freund <and...@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