Re: ON CONFLICT issues around whole row vars, - Mailing list pgsql-hackers

From Andres Freund
Subject Re: ON CONFLICT issues around whole row vars,
Date
Msg-id 20150929152447.GM5702@alap3.anarazel.de
Whole thread Raw
In response to Re: ON CONFLICT issues around whole row vars,  (Andres Freund <andres@anarazel.de>)
Responses Re: ON CONFLICT issues around whole row vars,  (Peter Geoghegan <pg@heroku.com>)
Re: ON CONFLICT issues around whole row vars,  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2015-09-24 17:25:21 +0200, Andres Freund wrote:
> Stuff I want to fix by tomorrow:
> * Whole row var references to exclude
> * wrong offsets for columns after dropped ones
> * INSTEAD DO UPDATE for tables with oids
>
> Do you know of anything else?

So, took a bit longer than "tomorrow. I fought for a long while with a
mysterious issue, which turned out to be separate bug: The excluded
relation was affected by row level security policies, which doesn't make
sense.

My proposal in this WIP patch is to make it a bit clearer that
'EXCLUDED' isn't a real relation. I played around with adding a
different rtekind, but that's too heavy a hammer. What I instead did was
to set relkind to composite - which seems to signal pretty well that
we're not dealing with a real relation. That immediately fixes the RLS
issue as fireRIRrules has the following check:
        if (rte->rtekind != RTE_RELATION ||
            rte->relkind != RELKIND_RELATION)
            continue;
It also makes it relatively straightforward to fix the system column
issue by adding an additional relkind check to scanRTEForColumn's system
column handling.

WRT to the wholerow issue: There's currently two reasons we need a
targetlist entry for excluded wholerow vars: 1) setrefs.c errors out
without - that can relativley easily be worked around 2) ruleutils.c
expects an entry in the child tlist. That could also be worked around,
but it's a bit more verbose.  I'm inclined to not go the pullup route
but instead simply unconditionally add a wholerow var to the excluded
tlist.

Peter, what do you think?

Andres

Attachment

pgsql-hackers by date:

Previous
From: Adam Brightwell
Date:
Subject: Re: unclear about row-level security USING vs. CHECK
Next
From: Andrew Dunstan
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!