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

Re: Feature proposal: www_fdw

From: "Dickson S(dot) Guedes" <listas(at)guedesoft(dot)net>
To: Alexander Soudakov <cygakob(at)gmail(dot)com>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Feature proposal: www_fdw
Date: 2011-09-29 12:45:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2011/9/28 Florian Pflug <fgp(at)phlo(dot)org>:
> On Sep28, 2011, at 15:32 , Alexander Soudakov wrote:
>> Here you can find www_fdw feature documentation:
> Certainly looks useful (as a third-party extension, as others have already pointed out)


> What I didn't quite understand is how one would pass (dynamic) parameters for a GET request. For example, not too long ago I needed to access the Google Maps API from postgres. I ended up using pl/python, and now wonder if your FDW would support that use-case.

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]?


Dickson S. Guedes
mail/xmpp: guedes(at)guedesoft(dot)net - skype: guediz -

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2011-09-29 12:53:33
Subject: Re: Does RelCache/SysCache shrink except when relations are deleted?
Previous:From: MauMauDate: 2011-09-29 12:23:48
Subject: Re: Does RelCache/SysCache shrink except when relations are deleted?

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