Re: [v9.3] writable foreign tables

2012/8/28 David Fetter <david(at)fetter(dot)org>:
> On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
>> 2012/8/28 David Fetter <david(at)fetter(dot)org>:
>> > On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
>> >> Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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.
>
One major problem is how to carry the generated identifiers on run-time,
even though we have no slot except for system and regular columns
defined in TupleDesc of the target foreign tables.
It may need a feature to expand TupleDesc on demand.

Of course, I don't deny the benefit of trigger support on foreign-tables.
Both writable-feature and trigger-support can be supported simultaneously.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>