On Thu, Jan 12, 2023 at 10:06 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Langote <amitlangot...@gmail.com> writes: > > On Mon, Jan 9, 2023 at 5:58 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Conceivably we could make it work by allowing RTE_SUBQUERY RTEs to > >> carry a relation OID and associated RTEPermissionInfo, so that when a > >> view's RTE_RELATION RTE is transmuted to an RTE_SUBQUERY RTE it still > >> carries the info needed to let us lock and permission-check the view. > >> That might be a bridge too far from the ugliness perspective ... > >> although certainly the business with OLD and/or NEW RTEs isn't very > >> pretty either. > > > I had thought about that idea but was a bit scared of trying it, > > because it does sound like something that might become a maintenance > > burden in the future. Though I gave that a try today given that it > > sounds like I may have your permission. ;-) > > Given the small number of places that need to be touched, I don't > think it's a maintenance problem. I agree with your fear that you > might have missed some, but I also searched and found no more.
While thinking about query view locking in context of [1], I realized that we have missed also fixing AcquirePlannerLocks() / ScanQueryForLocks() to consider that an RTE_SUBQUERY rte may belong to a view, which must be locked the same as RTE_RELATION entries. Note we did fix AcquireExecutorLocks() in 47bb9db75 as follows: @@ -1769,7 +1769,8 @@ AcquireExecutorLocks(List *stmt_list, bool acquire) { RangeTblEntry *rte = (RangeTblEntry *) lfirst(lc2); - if (rte->rtekind != RTE_RELATION) + if (!(rte->rtekind == RTE_RELATION || + (rte->rtekind == RTE_SUBQUERY && OidIsValid(rte->relid)))) Attached a patch to fix. -- Thanks, Amit Langote EDB: http://www.enterprisedb.com [1] https://commitfest.postgresql.org/42/3478/
ScanQueryForLocks-lock-views.patch
Description: Binary data