Re: Questions and experiences writing a Foreign Data Wrapper - Mailing list pgsql-hackers

From Albe Laurenz
Subject Re: Questions and experiences writing a Foreign Data Wrapper
Date
Msg-id D960CB61B694CF459DCFB4B0128514C206ABA030@exadv11.host.magwien.gv.at
Whole thread Raw
In response to Re: Questions and experiences writing a Foreign Data Wrapper  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas wrote:
>> 2) If I decide to close remote database connections after
>>     use, I would like to do so where reasonable.
>>     I would like to keep the connection open between query
>>     planning and query execution and close it when the
>>     scan is done.
>>     The exception could be named prepared statements.
>>     Is there a way to tell if that is the case during
>>     planing or execution?

> Hmm, maybe you could add a hook to close the connection when the
> transaction ends. But actually, you'd want to keep the connection
> open across transactions too. Some sort of a general connection
> caching facility would be useful for many FDW.

I agree, and that is how I implemented it at the moment.
But it might be nice to give the user the option, say, if they know
that it is a long session in a daemon process that accesses the
remote table only once a day.

I'll look into the hook option.

Here are some more ideas for FDW API functions/macros that might be
useful for FDW developers.

- A function that gives you the internal and external parameters at execution time.
- A function that gives you a type's input and output function.
- A function that gives you the OID of the foreign table owner.
- A function that gives you the list of columns of the foreign table (atttypid, atttypmod, attname, maybe others).

Yours,
Laurenz Albe


pgsql-hackers by date:

Previous
From: Shigeru Hanada
Date:
Subject: Re: Questions and experiences writing a Foreign Data Wrapper
Next
From: Yeb Havinga
Date:
Subject: Re: [v9.1] sepgsql - userspace access vector cache