From: | Marco Colombo <ing(dot)marco(dot)colombo(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Fetter <david(at)fetter(dot)org>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14351: Upsert not working in case of partitioned tables |
Date: | 2016-10-07 11:39:06 |
Message-ID: | CAOYH937w_kd6wRKrCsUM5h8G5MyDNyDC2Z7M3JQhCO_ieJzE9w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Thank you very much! Appreciated
2016-10-06 19:56 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Marco Colombo <ing(dot)marco(dot)colombo(at)gmail(dot)com> writes:
> > Hi, are information provided sufficient to reproduce the problem?
>
> I think you're hoping for a feature that doesn't exist, and is unlikely to
> do so anytime soon. The INSERT ... ON CONFLICT clause describes what to
> do in case the unique constraint on table dh_1 is violated. But it isn't,
> since indeed no insert into dh_1 happens at all. Some other constraint on
> some other table is being violated. The fact that that other insert is
> being driven from an ON-INSERT trigger belonging to dh_1 isn't enough to
> make a connection --- after all, that trigger could do anything at all.
>
> If we had a true partitioning feature where the connection between the
> table insertions was hardwired into the system (rather than emerging from
> user-written triggers) and the partitions were all guaranteed to have
> identical unique constraints, then it would be reasonable to expect INSERT
> ... ON CONFLICT to handle conflicts within the partitions. But we're
> still some ways away from having that.
>
> regards, tom lane
>
--
Ing. Marco Colombo
From | Date | Subject | |
---|---|---|---|
Next Message | hubert depesz lubaczewski | 2016-10-07 12:09:53 | Re: BUG #14359: serial datatype issue |
Previous Message | Zuk, Kacper | 2016-10-07 09:58:12 | Re: BUG #14329: libpq doesn't send complete client certificate chain on first SSL connection |