From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: ExecRTCheckPerms() and many prunable partitions (checkAsUser) |
Date: | 2023-02-17 12:02:46 |
Message-ID: | 20230217120246.525iztpb4z5dcgxp@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2022-Dec-11, Amit Langote wrote:
> While staring at the build_simple_rel() bit mentioned above, I
> realized that this code fails to set userid correctly in the
> inheritance parent rels that are child relations of subquery parent
> relations, such as UNION ALL subqueries. In that case, instead of
> copying the userid (= 0) of the parent rel, the child should look up
> its own RTEPermissionInfo, which should be there, and use the
> checkAsUser value from there. I've attached 0002 to fix this hole. I
> am not sure whether there's a way to add a test case for this in the
> core suite.
I gave this a look and I thought it was clearer to have the new
condition depend on rel->reloptkind instead parent or no.
I tried a few things for a new test case, but I was unable to find
anything useful. Maybe an intermediate view, I thought; no dice.
Maybe one with a security barrier would do? Anyway, for now I just kept
what you added in v2.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Attachment | Content-Type | Size |
---|---|---|
v3-0001-Correctly-set-userid-of-subquery-rel-s-child-rels.patch | text/x-diff | 6.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2023-02-17 12:05:58 | Re: ExecRTCheckPerms() and many prunable partitions (checkAsUser) |
Previous Message | vignesh C | 2023-02-17 11:04:22 | Re: Support logical replication of DDLs |