| From: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Emmanuel Cecchet <manu(at)asterdata(dot)com> |
| Cc: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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 02:16:14 |
| Message-ID: | 20091125111614.9284.52131E4D@oss.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Emmanuel Cecchet <manu(at)asterdata(dot)com> wrote:
> I guess the problem of handling user triggers is still open.
> If we allow triggers on partitions, badly written logic could lead to
> infinite loops in routing.
Infinite loops are not a partition-related problem, no?
We can also find infinite loops in user defined functions,
recursive queries, etc. I think the only thing we can do for it
is to *stop* loops instead of prevention, like max_stack_depth.
> With the current proposed implementation, would it be
> possible to define a view using child tables?
No, if you mean using a partition-view. I'm thinking we are moving
our implementation of partitioning from view-based to built-in feature.
Do you have any use-cases that requires view-based partitioning?
Was the inheritance-based partitioning not enough for it?
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2009-11-25 02:51:32 | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |
| Previous Message | Simon Riggs | 2009-11-25 02:13:10 | Re: KNNGiST for knn-search |