Re: Get access to the whole query in CustomScan path callback - Mailing list pgsql-hackers

From Amin
Subject Re: Get access to the whole query in CustomScan path callback
Date
Msg-id CAF-KA89c9W8fL5YQ1d9eSrhR5c4GEWVukvu4JSPdeEmJkX-_Wg@mail.gmail.com
Whole thread Raw
In response to Re: Get access to the whole query in CustomScan path callback  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I cannot find any information related to other relations in the query other than the one which is being scanned in the root pointer. Is there any function call which can be used to get access to it?

On Wed, Dec 21, 2022 at 9:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Amin <amin.fallahi@gmail.com> writes:
> The goal is to have access to all the tables that are being scanned or will
> be scanned as a part of the query. Basically, the callback looks like this:

> typedef void (*set_rel_pathlist_hook_type) (PlannerInfo *root,
>                                             RelOptInfo *rel,
>                                             Index rti,
>                                             RangeTblEntry *rte);

> Now, the problem is when there is a nested query, the function will be
> called once for the parent query and once for the subquery. However, I need
> access to the whole query in this function. There seems to be no CustomScan
> callback before this that has the whole query passed to it. Is there any
> way I can get access to the complete query (or all the relations in the
> query) by using the parameters passed to this function? Or any other
> workaround?

Everything the planner knows is accessible via the "root" pointer.

I very strongly question the idea that a custom scan provider should
be doing what you say you want to do, but the info is there.

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Amin
Date:
Subject: Get relid for a relation
Next
From: Thomas Munro
Date:
Subject: Re: Missed condition-variable wakeups on FreeBSD