| 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:28:45 |
| Message-ID: | 13723.1290702525@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:
> 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.
Or just specify a format for the extra information. Perhaps it could be
thought of as being a value of type bytea? Obviously we can't just have
a fixed amount of info, but maybe a blob with a length word is enough.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2010-11-25 16:35:20 | Re: reporting reason for certain locks |
| Previous Message | Heikki Linnakangas | 2010-11-25 16:24:04 | Re: SQL/MED - core functionality |