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