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 15:18:34 |
Message-ID: | CADyhKSVA2427QuV7SsxMgWj+mvRhxDbZny2zs+b5O55Cx-3pcw@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 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.
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.
Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Fabrízio de Royes Mello | 2012-08-28 15:19:40 | Re: CREATE SCHEMA IF NOT EXISTS |
Previous Message | Alvaro Herrera | 2012-08-28 15:09:34 | Re: pg_dump incorrect output in plaintext mode |