Re: Column defaults for foreign tables (was Re: [v9.3] writable foreign tables)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Cc: "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Column defaults for foreign tables (was Re: [v9.3] writable foreign tables)
Date: 2013-03-13 19:04:35
Message-ID: 2595.1363201475@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-03-13 19:10:04 Re: Statistics and selectivity estimation for ranges
Previous Message David E. Wheeler 2013-03-13 18:32:06 Re: Duplicate JSON Object Keys