Re: [v9.3] writable foreign tables

Thom Brown <thom(at)linux(dot)com> writes:
> On 10 March 2013 18:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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