2012/8/28 David Fetter <david@fetter.org>:
> On Tue, Aug 28, 2012 at 06:08:59PM +0200, Kohei KaiGai wrote:
>> 2012/8/28 David Fetter <david@fetter.org>:
>> > 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.
>> >
>> > 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.
>
> Could be. You know a lot more about the implementation details than I do.
>
>> Of course, I don't deny the benefit of trigger support on foreign-tables.
>> Both writable-feature and trigger-support can be supported simultaneously.
>
> Do you see these as independent features, or is there some essential
> overlap?
>
If we stand on the viewpoint that foreign-tables should perform as if regular
tables, I don't think its writer feature should depend on trigger stuff.
They can work independently.
On the other hand, trigger feature gives users flexibility to control the data
to be written, as if regular tables. We shouldn't miss the point.
At least, I don't think we have some technical differences to support row-level
triggers on foreign tables.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>