Skip site navigation (1) Skip section navigation (2)

Re: Feature proposal: www_fdw

From: Florian Pflug <fgp(at)phlo(dot)org>
To: "Dickson S(dot) Guedes" <listas(at)guedesoft(dot)net>
Cc: Alexander Soudakov <cygakob(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Feature proposal: www_fdw
Date: 2011-09-29 13:59:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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 (
- they presumably re-use the same connection over multiple foreign scans,
which seems to be a problem similar to yours.

best regards,
Florian Pflug

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-09-29 13:59:26
Subject: Re: Does RelCache/SysCache shrink except when relations are deleted?
Previous:From: Alvaro HerreraDate: 2011-09-29 13:44:29
Subject: Re: pg_upgrade - add config directory setting

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group