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 |
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 |
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 |