On Thu, Jan 21, 2016 at 4:05 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: >> By the way, I'm not too sure I understand the need for the core >> changes that are part of this patch, and I think that point merits >> some discussion. Whenever you change core like this, you're changing >> the contract between the FDW and core; it's not just postgres_fdw that >> needs updating, but every FDW. So we'd better be pretty sure we need >> these changes and they are adequately justified before we think about >> putting them into the tree. Are these core changes really needed >> here, or can we fix this whole issue in postgres_fdw and leave the >> core code alone? > > Well, if we think it is the FDW's responsibility to insert a valid value for > tableoid in the returned slot during ExecForeignInsert, ExecForeignUpdate or > ExecForeignDelete, we don't need those core changes. However, I think it > would be better that that's done by ModifyTable in the same way as > ForeignScan does in ForeignNext, IMO. That eliminates the need for > postgres_fdw or any other FDW to do that business in the callback routines.
I'm not necessarily opposed to the core changes, but I want to understand better what complexity they are avoiding. Can you send a version of this patch that only touches postgres_fdw, so I can compare? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
