Re: SQL/MED - core functionality
От | Heikki Linnakangas |
---|---|
Тема | Re: SQL/MED - core functionality |
Дата | |
Msg-id | 4CEE8DA4.7000201@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: SQL/MED - core functionality (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SQL/MED - core functionality
|
Список | 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
В списке pgsql-hackers по дате отправления: