From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bernd Helmle <mailings(at)oopsware(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Passing fdw_private data from PlanForeignScan to PlanForeignModify |
Date: | 2013-06-13 15:06:31 |
Message-ID: | 22682.1371135991@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bernd Helmle <mailings(at)oopsware(dot)de> writes:
> During the planning phase, the Informix FDW currently plans a server side
> cursor, which identifier i'd like to pass into the planning phase of the
> modify action to reuse it in conjunction with UPDATE ... WHERE CURRENT OF.
> I understand that the ModifyTable structure passed to PlanForeignModify has
> a list of associated plan nodes, from which i can access the ForeignScan
> plan node associated with the current modify action, thus having access to
> the fdw_private data generated during the planning phase of the ForeigScan
> node. However, it's a list and i currently don't understand on how to
> reference the associated ForeignScan node reliably, given that there are
> cases with more than one node in this list.
The subplan_index argument to PlanForeignModify is the list index to
use, unless I'm misunderstanding something about this. However, in join
cases the ForeignScan node will be buried down inside a join nest, so
locating it in the plan tree could be rather difficult. My
recommendation would be to see if you can't save the relevant info in
the RelOptInfo node for the relation, probably during GetForeignPlan,
and then get it from there in PlanForeignModify instead of digging in
the plan tree. (You can use the fdw_private field of RelOptInfo for
whatever you need in this line.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2013-06-13 16:57:27 | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) |
Previous Message | Amit Kapila | 2013-06-13 12:35:17 | ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |