On 13 March 2013 19:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
How about:
CREATE FOREIGN TABLE tablename (id int DEFAULT PASSTHROUGH) SERVER pg_server;
That way it will pass DEFAULT through to the remote table as it's
defined on the table. Users can then explicitly insert values, or
select the default, which will configured to ensure the default on the
remote server is used... although I suspect I'm overlooking something
here.
--
Thom