| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Hannu Krosing <hannu(at)2ndquadrant(dot)com> |
| Cc: | Emmanuel Cecchet <manu(at)asterdata(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Emmanuel Cecchet <Emmanuel(dot)Cecchet(at)asterdata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Partitioning option for COPY |
| Date: | 2009-11-25 14:14:57 |
| Message-ID: | 603c8f070911250614v9a4af61v6910f362896fc20@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 25, 2009 at 5:03 AM, Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
> I'd propose that triggers on both parent table and selected child are
> executed.
I was thinking we should make the partitioning decision FIRST, before
any triggers are fired, and then fire only those triggers relevant to
the selected partition. If the BEFORE triggers on the partition
modify the tuple in a way that makes it incompatible with the table
constraints on that partition, the insert (or update) fails.
Firing triggers on more than one table is pretty substantially
incompatible with what we do elsewhere and I'm not clear what we get
in exchange. What is the use case for this?
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Emmanuel Cecchet | 2009-11-25 14:21:21 | Re: Partitioning option for COPY |
| Previous Message | Robert Haas | 2009-11-25 14:05:44 | Re: SE-PgSQL patch review |