Re: Fwd: Problem with a "complex" upsert

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Mario De Frutos Dieguez <mariodefrutos(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Fwd: Problem with a "complex" upsert
Date: 2018-08-04 22:37:09
Message-ID: 22581.1533422229@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-bugs

I wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> I think we definitely should try to get this in.

> Well, if you're excited about it, help Dean review it.

So, in the spirit of "put your money where your mouth is", I've been
working off-list with Dean today to review this patch. We found a couple
additional minor issues:

* We noticed that the rewriter was expanding the EXCLUDED
pseudo-relation's RTE into an RTE_SUBQUERY RTE, rather than leaving it
in the intended form as an RTE_RELATION RTE with a nonstandard rtekind.
(This happens basically always with a view target rel in the existing
code, but only in corner cases after Dean's patch.) While this doesn't
seem to have obvious bad effects, it's both unintended and a waste of
cycles. Also, the fact that this area seems rather undertested leaves
me not wanting to have weird data structure differences that happen
only in corner cases. So we added a check to fireRIRrules to prevent
that from happening.

* We happened across some unexpected permissions failures while checking
the patch in cases where the calling user is not the view owner. This
turned out to be because of a pre-existing oversight: the replacement
EXCLUDED RTE is initially manufactured with requiredPerms = ACL_SELECT,
and nothing was getting done to change that, leading to failure if the
calling user doesn't have SELECT on the underlying table. (The desired
behavior is that the view owner needs permissions on the underlying table,
but the calling user only needs permissions on the view.) So that's
easily fixed by zeroing out requiredPerms in the EXCLUDED RTE; nothing is
lost because other code was already adding the required permission check
flags to the query's actual target relation. But out of paranoia we added
a bunch of permissions-checking test cases to updatable_views.sql.

Attached is our finished patch against HEAD. This is pretty much all
Dean's work, but I'm posting it on his behalf because it's late in the UK
and he's gone offline for the day. In the interests of getting a
full set of buildfarm testing on the patch before Monday's wrap deadline,
I'm going to finish up back-porting the patch and push it tonight.

regards, tom lane

Attachment Content-Type Size
insert-on-conflict-on-updatable-view-v4.patch text/x-diff 26.1 KB

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Mariel Cherkassky 2018-08-05 08:58:37 PostgreSQL 11 global index
Previous Message Peter Geoghegan 2018-08-04 00:01:01 Re: Fwd: Problem with a "complex" upsert

Browse pgsql-bugs by date

  From Date Subject
Next Message Yahor Yuzefovich 2018-08-06 14:56:59 Docker image of 11~beta2-2 orders strings case-insensitively
Previous Message Peter Geoghegan 2018-08-04 00:01:01 Re: Fwd: Problem with a "complex" upsert