Re: A bug with ExecCheckPermissions - Mailing list pgsql-hackers

From Amit Langote
Subject Re: A bug with ExecCheckPermissions
Date
Msg-id CA+HiwqHjZv+F3-A7E7xAc8=KGCSGKsF1+4Uu-UUTu+3AK5N1pg@mail.gmail.com
Whole thread Raw
In response to Re: A bug with ExecCheckPermissions  (Sergey Shinderuk <s.shinderuk@postgrespro.ru>)
Responses Re: A bug with ExecCheckPermissions  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Hi,

On Thu, Feb 9, 2023 at 14:44 Sergey Shinderuk <s.shinderuk@postgrespro.ru> wrote:
On 08.02.2023 21:23, Alvaro Herrera wrote:
> On 2023-Feb-08, Amit Langote wrote:
>
>> On Wed, Feb 8, 2023 at 16:19 Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
>>> I think we should also patch ExecCheckPermissions to use forboth(),
>>> scanning the RTEs as it goes over the perminfos, and make sure that the
>>> entries are consistent.
>>
>> Hmm, we can’t use forboth here, because not all RTEs have the corresponding
>> RTEPermissionInfo, inheritance children RTEs, for example.
>
> Doh, of course.
>
>> Also, it doesn’t make much sense to reinstate the original loop over
>> range table and fetch the RTEPermissionInfo for the RTEs with non-0
>> perminfoindex, because the main goal of the patch was to make
>> ExecCheckPermissions() independent of range table length.
>
> Yeah, I'm thinking in a mechanism that would allow us to detect bugs in
> development builds — no need to have it run in production builds.
> However, I can't see any useful way to implement it.
>


Maybe something like the attached would do?

Thanks for the patch.  Something like this makes sense to me.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Dag Lem
Date:
Subject: Re: daitch_mokotoff module
Next
From: "Takamichi Osumi (Fujitsu)"
Date:
Subject: RE: Time delayed LR (WAS Re: logical replication restrictions)