On 11 March 2013 19:00, Greg Stark <stark@mit.edu> wrote:
> On Sun, Mar 10, 2013 at 10:01 PM, Tom Lane <tgl@sss.pgh.pa.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....
We could have something like:
CREATE FOREIGN TABLE ...
... OPTION (default <locality>);
where <locality> is 'local' or 'remote'. But then this means it still
can't be specified in individual queries, or have a different locality
between columns on the same foreign table.
--
Thom
