Re: SQL/MED - core functionality
От | Heikki Linnakangas |
---|---|
Тема | Re: SQL/MED - core functionality |
Дата | |
Msg-id | 4CEE927A.2050303@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:28, Tom Lane wrote: > Heikki Linnakangas<heikki.linnakangas@enterprisedb.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. That seems quite awkward to work with. Let's at least make it a Node *, so that you can store a Value or List there, or anything else that already has copyObject support. I think the PostgreSQL FDW would want to store the remote query there. But it's not a stretch that you want to use parameter markers in the remote query, with the parameter values determined at runtime. In that case you'd also store a list of Exprs for the parameter values (Hmm, BeginScan needs an ExprContext for that..). This is very hand-wavy, but I think we'll hit the wall with a single blob pretty quickly. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: