Albe Laurenz <laurenz.albe@wien.gv.at> writes:
>> Yeah, I'm drifting towards the position that we should just define the
>> defaults as being whatever they are locally, rather than trying to be
>> cute about supporting remotely-executed defaults.
> That was my first thought on the topic, to have a solution that
> is simple (if not perfect).
> Your argument that it would be unpleasant to lose the ability
> to use sequence-generated remote default values made me reconsider.
> But there is a workaround, namely to use a trigger before insert
> to generate an automatic primary key (e.g. if the inserted value is
> NULL).
Another attack is to set up a different foreign table pointing to the
same remote table, but lacking the sequence column. When you insert via
that table, you'll get the remote's default for the hidden column.
This doesn't require any weird triggers on the remote side, but it could
be hard to persuade existing apps to use the second foreign table.
regards, tom lane