Re: [v9.3] writable foreign tables
Kohei KaiGai <kaigai@kaigai.gr.jp>
From: Kohei KaiGai <kaigai@kaigai.gr.jp>
To: David Fetter <david@fetter.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Shigeru HANADA <shigeru.hanada@gmail.com>, PgHacker <pgsql-hackers@postgresql.org>
Date: 2012-08-28T15:18:34Z
Lists: pgsql-hackers
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. > > 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@kaigai.gr.jp>
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix postgres_fdw's issues with inconsistent interpretation of data values.
- cc3f281ffb0a 9.3.0 cited