On 11 March 2013 19:00, Greg Stark <st...@mit.edu> wrote: > On Sun, Mar 10, 2013 at 10:01 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
