Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Farina <daniel@heroku.com>
Cc: Josh Berkus <josh@agliodbs.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2013-03-12T02:04:08Z
Lists: pgsql-hackers
Daniel Farina <daniel@heroku.com> writes: > I will try to make time for this, although it seems like the general > approach should match pgsql_fdw if possible. Is the current thinking > to forward the settings and then use the GUC hooks to track updates? That's not what I had in mind for postgres_fdw --- rather the idea is to avoid needing on-the-fly changes in remote-side settings, because those are so expensive to make. However, postgres_fdw is fortunate in that the SQL it expects to execute on the remote side is very constrained. dblink might need a different solution that would leave room for user-driven changes of remote-side settings. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix postgres_fdw's issues with inconsistent interpretation of data values.
- cc3f281ffb0a 9.3.0 cited