| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Emmanuel Cecchet <manu(at)asterdata(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Emmanuel Cecchet <Emmanuel(dot)Cecchet(at)asterdata(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Partitioning option for COPY |
| Date: | 2009-11-25 23:28:29 |
| Message-ID: | 603c8f070911251528rd254525t4c13e05621a571e@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 25, 2009 at 11:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> It seems like the easiest way to resolve this without weird corner
> cases is to say that we fire triggers belonging to the parent table.
> The individual partition child tables either shouldn't have triggers
> at all, or we should restrict the cases in which those are considered
> applicable.
>
> As an example, what are you going to do with statement-level triggers?
> Fire them for *every* child whether it receives a row or not? Doesn't
> seem like the right thing.
Just the tables that get a row? I don't know, your way may be best,
but it seems like tables on individual partitions might be useful in
some situations.
> Again, this solution presupposes an explicit concept of partitioned
> tables within the system...
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2009-11-25 23:59:43 | Re: operator exclusion constraints |
| Previous Message | Hannu Krosing | 2009-11-25 23:04:36 | Re: Partitioning option for COPY |