| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: Re: 9.5 release notes may need ON CONFLICT DO NOTHING compatibility notice for FDW authors |
| Date: | 2015-05-29 20:45:09 |
| Message-ID: | CAM3SWZTZ7xiuABX4tJXFc99r843e3sdFA67bUPUJkY29KdiY9A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 28, 2015 at 1:20 AM, Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> I think that those are interesting problems. Wouldn't we need some
> additional hacks for the core or FDW to perform an operation that is
> equivalent to dynamically switching the ExecInsert/ExecForeignInsert
> processing to the ExecUpdate/ExecForeignUpdate processing in case of a
> conflict?
I did not imagine so. Rather, I thought that it was a matter of simply
introducing a way that foreign tables can have foreign constraints
recognizable by the local Postgres optimizer. The decision to insert
or update must belong to the foreign server, since the feature could
be useful for systems like MySQL, and not just Postgres. I may be
mistaken.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2015-05-29 20:50:04 | Re: Need Force flag for pg_drop_replication_slot() |
| Previous Message | Simon Riggs | 2015-05-29 20:41:27 | Re: Need Force flag for pg_drop_replication_slot() |