From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thom Brown <thom(at)linux(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.3] writable foreign tables |
Date: | 2013-03-11 19:00:44 |
Message-ID: | CAM-w4HNPHookzP4ZwdQEXcUWT_4B0+tjcmZP6QFsu93_f4ptkg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Mar 10, 2013 at 10:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Another thing that would be easy to implement is to say that the new row
> value is fully determined locally (including defaults if any) and remote
> defaults have nothing to do with it. But I think that's almost
> certainly a usability fail --- imagine that the remote has a
> sequence-generated primary key, for instance. I think it's probably
> necessary to permit remote insertion of defaults for that sort of table
> definition to work conveniently.
It feels a bit like unpredictable magic to have "DEFAULT" mean one
thing and omitted columns mean something else. Perhaps we should have
an explicit LOCAL DEFAULT and REMOTE DEFAULT and then have DEFAULT and
omitted columns both mean the same thing.
This starts getting a bit weird if you start to ask what happens when
the remote table is itself an FDW though....
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-03-11 19:06:54 | Re: [v9.3] writable foreign tables |
Previous Message | Tom Lane | 2013-03-11 18:50:48 | Column defaults for foreign tables (was Re: [v9.3] writable foreign tables) |