| From: | Andy S <gatekeeper(dot)mail(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #16714: INSERT ON CONFLICT DO UPDATE fails to infer constraint if it's not at top-level partition |
| Date: | 2020-11-14 14:11:44 |
| Message-ID: | CAFAcjJP2wmSU35b=XuOYd3x_HF123kmycrVwRkT4Chn37APKDA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sat, Nov 14, 2020 at 3:28 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> At best it is a potentially desirable feature. One that isn't trivial to
> implement. We'd have to scan the entire partition tree to ensure there's
> a matching constraint on all partitions.
>
https://www.postgresql.org/docs/11/ddl-partitioning.html#DDL-PARTITIONING-DECLARATIVE-LIMITATIONS
- BEFORE ROW triggers...
So, the engine does exactly what you say for each row to determine if *the
leaf* partition has any BEFORE ROW triggers defined. Why not to use the
chance to determine a certain applicable constraint set?
> That is not generally the case. You can have parametrized values that
> are inserted, and you can have multi-row inserts. In both cases you
> cannot make this decision at plan time.
>
OK. Then I've mistaken, sorry for that. Still `uniq constraint violation`
triggers even when it's not defined for the very table named in query.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2020-11-14 15:06:08 | Re: Data format mismatch between minor versions |
| Previous Message | Sergei Kornilov | 2020-11-14 13:50:02 | Re: Data format mismatch between minor versions |