From: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Shigeru HANADA <shigeru(dot)hanada(at)gmail(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.3] writable foreign tables |
Date: | 2012-08-28 16:08:59 |
Message-ID: | CADyhKSUKuGj=TAUYub2yShamJxMccViGPDYvhhpdQi3mdYENRA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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>
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2012-08-28 16:14:47 | Re: Advisory Lock BIGINT Values |
Previous Message | David E. Wheeler | 2012-08-28 16:08:13 | Re: CREATE SCHEMA IF NOT EXISTS |