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 →
  1. Fix postgres_fdw's issues with inconsistent interpretation of data values.