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

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 08:07:25
Message-ID: A737B7A37273E048B164557ADEF4A58B057BDE89@ntex2010a.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> 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. It looks to me like
> if we try to do the latter, we're going to have pitfalls and weird
> corner cases that will never be quite transparent. There's also the
> argument that this'd be a lot of work that benefits only some FDWs,
> since the whole concept of remote column defaults doesn't apply when
> the FDW's data source isn't a traditional RDBMS.

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).
Maybe it would be good to add a few hints at workarounds like that
to the documentation if it's going to be local defaults.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Boszormenyi Zoltan 2013-03-13 08:09:24 Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Previous Message Magnus Hagander 2013-03-13 07:39:01 Re: leaking lots of unreferenced inodes (pg_xlog files?), maybe after moving tables and indexes to tablespace on different volume