| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Remove mention in docs that foreign keys on partitioned tables are not supported |
| Date: | 2018-06-04 21:37:46 |
| Message-ID: | cc95fb54-4c02-f0e6-46eb-e587a96eaf0f@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 6/4/18 16:50, Tom Lane wrote:
> Perhaps, but I'm having a hard time wrapping my mind around what the
> semantics ought to be. If a trigger on partition A changes the keys
> so that the row shouldn't have gone into A at all, what then? That
> trigger should never have fired, eh?
The insert will result in an error and everything is rolled back, so you
do kind of get the "should never have" behavior.
It seems we ultimately have to answer the question whether we want
BEFORE triggers executed before or after tuple routing. Both behaviors
might be useful, so perhaps we'll need two kinds of triggers.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-06-04 21:40:43 | Re: Remove mention in docs that foreign keys on partitioned tables are not supported |
| Previous Message | Justin Clift | 2018-06-04 21:31:12 | Re: Code of Conduct plan |