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?
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
