Re: [v9.3] writable foreign tables
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Stark <stark@mit.edu>
Cc: Thom Brown <thom@linux.com>, Kohei KaiGai <kaigai@kaigai.gr.jp>, Daniel Farina <daniel@heroku.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2013-03-11T19:06:54Z
Lists: pgsql-hackers
Greg Stark <stark@mit.edu> writes: > It feels a bit like unpredictable magic to have "DEFAULT" mean one > thing and omitted columns mean something else. Agreed. The current code behaves that way, but I think that's indisputably a bug not behavior we want to keep. > Perhaps we should have > an explicit LOCAL DEFAULT and REMOTE DEFAULT and then have DEFAULT and > omitted columns both mean the same thing. I don't think we really want to introduce new syntax for this, do you? Especially not when many FDWs won't have a notion of a remote default at all. My thought was that the ideal behavior is that there's only one default for a column, with any local definition of it taking precedence over any remote definition. But see later message about how that may be hard to implement correctly. 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