Re: on placeholder entries in view rule action query's range table

On Thu, Jan 12, 2023 at 10:06 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Langote <amitlangote09@gmail.com> writes:
> > On Mon, Jan 9, 2023 at 5:58 AM Tom Lane <tgl@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/