Just be careful with FDWs. They run outside of many of the normal checks within the PG server and so a badly written FDW can actually cause the whole server to crash. We've experienced a number of issues with the MongoDB FDW from Citus where we do benign things like comparing an integer to a string and the entire Postgres server goes down. Another issues we've run into is that the query planning cache seems to get confused by FDWs, and if we try to query an FDW from within a stored procedure it just never returns or it crashes the DB. Instead we have to construct the query with dynamic SQL inside the stored proc which is both a pain in the ass and way increases the chances for bugs.<p>We're still on 9.1 so maybe some of this has been fixed by now but people seem to push FDWs as this panacea where you get all the guarantees & safety of running within Postgres and that's just not the case.
<a href="http://multicorn.org/" rel="nofollow">http://multicorn.org/</a> is a PostgreSQL extension meant to make FDW development easier. It lets you write them in Python.
Unrelated but important: I wish sites realized that blocking Adobe Typekit (and it's tracking) totally breaks their site. In this particular one I don't see any text.
Why the hell is there no fallback for crappy fonts or whatever?
Heroku's implemented a streamlined version that they support called Data Links. <a href="https://blog.codeship.com/heroku-data-links-postgres-redis/" rel="nofollow">https://blog.codeship.com/heroku-data-links-postgres-redis/</a>