Re: Feature proposal: www_fdw - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: Feature proposal: www_fdw
Date
Msg-id 1A010B54-C8D3-4C02-9554-D4A5148FFD84@phlo.org
Whole thread Raw
In response to Re: Feature proposal: www_fdw  ("Dickson S. Guedes" <listas@guedesoft.net>)
Responses Re: Feature proposal: www_fdw
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_upgrade - add config directory setting
Next
From: Robert Haas
Date:
Subject: Re: Does RelCache/SysCache shrink except when relations are deleted?