Thom Brown <t...@linux.com> writes: > On 10 March 2013 18:32, Tom Lane <t...@sss.pgh.pa.us> wrote: >> There's a lot left to do here of course. One thing I was wondering >> about was why we don't allow DEFAULTs to be attached to foreign-table >> columns. There was no use in it before, but it seems sensible enough >> now.
> postgres=# INSERT INTO animals (id, animal, age) VALUES (DEFAULT, > 'okapi', NULL); > ERROR: null value in column "id" violates not-null constraint > DETAIL: Failing row contains (null, okapi, null). > Out of curiosity, is there any way to explicitly force a foreign > DEFAULT with column-omission? That's one of the things that would have to be worked out before we could implement anything here. The easy answer would be that DEFAULT specifies the local default, and only if you omit the column entirely from the local command (including not having a local default) does the remote default take effect. But whether that would be convenient to use is hard to tell. 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. Not real sure what the ideal behavior would be or how hard it would be to implement. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers