Re: Feature proposal: www_fdw

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: Feature proposal: www_fdw
Дата
Msg-id 1A010B54-C8D3-4C02-9554-D4A5148FFD84@phlo.org
обсуждение исходный текст
Ответ на Re: Feature proposal: www_fdw  ("Dickson S. Guedes" <listas@guedesoft.net>)
Ответы Re: Feature proposal: www_fdw
Список pgsql-hackers
On Sep29, 2011, at 14:45 , Dickson S. Guedes wrote:
> I'm working on a google_contacts_fdw to google contacts api [1] but
> stopped in the authentication design. As you can see in [2], for
> google api, you should get an authorization token and store the "Auth"
> value to use latter on the same "session". I'm wondering how the best
> way to "cache" this value as long as possible, because actually, when
> you need authentication for a FDW, you use the
> fdw_routine->BeginForeignScan call function but, in this situation,
> each SELECT to foreign table will do the handshake and some APIs could
> block this. Many client libraries work fine, caching the Auth value.
> How WWW_FDW could play with behaviors like that, since other Web APIs
> has the a authorization system like this [2]?

You could use a hash table, allocated in the top-level memory context,
to store one authentication token per combination of server and local user.

I suggest you look at the MySQL FDW (https://github.com/dpage/mysql_fdw)
- they presumably re-use the same connection over multiple foreign scans,
which seems to be a problem similar to yours.

best regards,
Florian Pflug



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_upgrade - add config directory setting
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Does RelCache/SysCache shrink except when relations are deleted?