Re: on placeholder entries in view rule action query's range table
От | Amit Langote |
---|---|
Тема | Re: on placeholder entries in view rule action query's range table |
Дата | |
Msg-id | CA+HiwqHr-ob3oJh-_jqR5Otkk6tDhnsFFRQKMDLKzqRseMGGTA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: on placeholder entries in view rule action query's range table (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, Apr 6, 2023 at 3:33 Tom Lane <tgl@sss.pgh.pa.us> wrote:
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;
Oops, I was working in the wrong local branch.
Thanks for pushing. I agree that there’s no live bug as such right now, but still good to be consistent.
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: