From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL/MED - core functionality |
Date: | 2010-11-25 16:24:04 |
Message-ID: | 4CEE8DA4.7000201@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 25.11.2010 18:18, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-25 16:28:45 | Re: SQL/MED - core functionality |
Previous Message | Tom Lane | 2010-11-25 16:23:42 | Re: reporting reason for certain locks |