Re: SQL/MED - core functionality

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
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:18:23
Message-ID: 13484.1290701903@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. That is entirely
unworkable/unacceptable: quite aside from the semantic ugliness, it will
fail altogether for cached plans.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-11-25 16:23:42 Re: reporting reason for certain locks
Previous Message Tom Lane 2010-11-25 16:14:11 Re: reporting reason for certain locks