| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: UPSERT on partition |
| Date: | 2015-06-24 14:38:38 |
| Message-ID: | CA+TgmoZUc4rSjfkm4jhg4fsL5CB4nqEipfypNeLntXWQUc4hEQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 24, 2015 at 10:29 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2015-06-24 23:05:45 +0900, Fujii Masao wrote:
>> INSERT ON CONFLICT DO UPDATE doesn't seem to work on the current partitioning
>> mechanism. For example, in the following SQL commands, the last UPSERT command
>> would fail with an error. The error message is
>
> I think that's pretty much inevitable without baking in touple routing
> into the core system and supporting unique-constraints that span
> partitions. In other words, I don't think this is upsert's fault.
Is the root of the problem that the trigger is called for an INSERT ..
ON CONFLICT statement but it turns that into a plain INSERT?
Is there any way of writing a partitioning trigger that doesn't have
that defect?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-06-24 14:41:48 | Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?) |
| Previous Message | Fujii Masao | 2015-06-24 14:30:08 | Re: Support for N synchronous standby servers - take 2 |