Message-ID: <3c810344-94b3-19a6-26d0-e6350a0b811f@pgmasters.net>
Date: Fri, 9 Jun 2023 12:04:55 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.11.1
Subject: Re: Views no longer in rangeTabls?
Content-Language: en-US
From: David Steele <david@pgmasters.net>
To: Pg Hackers <pgsql-hackers@postgresql.org>,
 Amit Langote <amitlangote09@gmail.com>
References: <3953179e-9540-e5d1-a743-4bef368785b0@pgmasters.net>
In-Reply-To: <3953179e-9540-e5d1-a743-4bef368785b0@pgmasters.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/3c810344-94b3-19a6-26d0-e6350a0b811f%40pgmasters.net>
Precedence: bulk

On 6/9/23 11:28, David Steele wrote:
> 
> It seems the thing to do here would be to scan permInfos instead, which 
> works fine except that we also need access to rellockmode, which is only 
> included in rangeTabls. We can add a scan of rangeTabls to get 
> rellockmode when needed and we might be better off overall since 
> permInfos will generally have fewer entries. I have not implemented this 
> yet but it seems like it will work.

I implemented this and it does work, but it was not as straight forward 
as I would have liked. To make the relationship from RTEPermissionInfo 
back to RangeTblEntry I was forced to generate my own perminfoindex.

This was not hard to do but seems a bit fragile. Perhaps we need an 
rteindex in RTEPermissionInfo? This would also avoid the need to scan 
rangeTabls.

Regards,
-David