On Tue, Aug 28, 2012 at 06:08:59PM +0200, Kohei KaiGai wrote: > 2012/8/28 David Fetter <da...@fetter.org>: > > On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote: > >> 2012/8/28 David Fetter <da...@fetter.org>: > >> > On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote: > >> >> Kohei KaiGai <kai...@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 <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers