Re: SQL/MED - core functionality
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Itagaki Takahiro <itagaki.takahiro@gmail.com>, Shigeru HANADA <hanada@metrosystems.co.jp>, pgsql-hackers@postgresql.org
Date: 2010-11-25T16:24:04Z
Lists: pgsql-hackers
On 25.11.2010 18:18, Tom Lane wrote: > Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes: >> I left out some details on what exactly FdwPlan should contain and what >> it's lifecycle should be. I'm thinking that it should be allocated in >> the CurrentMemoryContext that's active when the FDW Plan routine is >> called, which would be the same context where we store all the Plan >> objects. It should not be modified after creation, so that it doesn't >> need to be copied when the ForeignScan is copied with copyObject(). It >> should not contain transient state information like connection objects, >> or references to a remotely prepared cursor etc. It must be possible to >> call BeginScan multiple times with the same FdwPlan object, so that it >> can be stored in a prepared plan that is executed multiple times. > > The above statements seem mutually contradictory. In particular, > I think you're proposing that copyObject copy only a pointer and not the > whole plan tree when copying ForeignScan. Right. > That is entirely > unworkable/unacceptable: quite aside from the semantic ugliness, it will > fail altogether for cached plans. Hmm, I see, cached plans are planned in a shorter-lived context first, and copied to permanent storage afterwards. Needs more thought then. Maybe the FDW needs to provide a copyFdwPlan() function to copy FdwPlans returned by that FDW. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com