Re: [v9.3] writable foreign tables

On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
> 2012/8/28 David Fetter <david@fetter.org>:
> > On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
> >> Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
> >> > It seems to me TargetEntry of the parse tree can inform us
> >> > which column should be modified on UPDATE or INSERT. If it has
> >> > just a Var element that reference original table as-is, it
> >> > means here is no change.
> >>
> >> Only if you're not going to support BEFORE triggers modifying the
> >> row...
> >
> > +1 for supporting these.
> >
> > Speaking of triggers on foreign tables, what's needed to support
> > them independent of support at the FDW level for writing on
> > foreign tables, or does that even make sense?
> >
> I agree with trigger support on foreign tables is definitely useful
> feature, even though it does not have capability to replace the
> writable foreign table functionality.

With utmost respect, trigger support does make it possible to write to
foreign tables using a whole-row comparison with the effect that all
whole-row matches would be affected.  This is how DBI-Link does it
currently.

> In case when foreign-table definition does not contain a column
> mapped with primary-key column in remote-side, the trigger function
> cannot determine which row should be updated / deleted.  It is a
> situation that FDW driver should track a particular remote-row using
> its identifier.

Generated identifiers and whole-row matching are two ways to approach
this.  There are likely others, especially in cases where people have
special knowledge of the remote source.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate