Re: on placeholder entries in view rule action query's range table - Mailing list pgsql-hackers

From Tom Lane
Subject Re: on placeholder entries in view rule action query's range table
Date
Msg-id 2016650.1680719613@sss.pgh.pa.us
Whole thread Raw
In response to Re: on placeholder entries in view rule action query's range table  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: on placeholder entries in view rule action query's range table  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: on placeholder entries in view rule action query's range table  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
> 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.

I think you're right about that, because AcquirePlannerLocks is supposed
to reacquire whatever locks parsing+rewriting would have gotten.
However, what's with this hunk?

@@ -527,7 +527,7 @@ standard_planner(Query *parse, const char *query_string, int cursorOptions,
     result->partPruneInfos = glob->partPruneInfos;
     result->rtable = glob->finalrtable;
     result->permInfos = glob->finalrteperminfos;
-    result->viewRelations = glob->viewRelations;
+    result->viewRelations = NIL;
     result->resultRelations = glob->resultRelations;
     result->appendRelations = glob->appendRelations;
     result->subplans = glob->subplans;

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Minimal logical decoding on standbys
Next
From: Daniel Gustafsson
Date:
Subject: Re: GUC for temporarily disabling event triggers