Re: SQL/MED - core functionality - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SQL/MED - core functionality
Date
Msg-id 13484.1290701903@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQL/MED - core functionality  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: SQL/MED - core functionality
List pgsql-hackers
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.  That is entirely
unworkable/unacceptable: quite aside from the semantic ugliness, it will
fail altogether for cached plans.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: reporting reason for certain locks
Next
From: Tom Lane
Date:
Subject: Re: reporting reason for certain locks