On Wed, Jan 10, 2007 at 04:39:06PM -0500, Steven Flatt wrote:
> On 1/10/07, Jim C. Nasby <jim(at)nasby(dot)net> wrote:
> >
> >Except for the simplest partitioning cases, you'll be much better off
> >using a trigger on the parent table to direct inserts/updates/deletes to
> >the children. As a bonus, using a trigger makes it a lot more realistic
> >to deal with an update moving data between partitions.
>
>
> In our application, data is never moved between partitions.
>
> The problem I found with triggers is the non-robustness of the PLpgSQL
> record data type. For example, in an "on insert" trigger, I can't determine
> the fields of the NEW record unless I hard code the column names into the
> trigger. This makes it hard to write a generic trigger, which I can use for
> all our partitioned tables. It would have been somewhat of a pain to write
> a separate trigger for each of our partitioned tables.
>
> For that and other reasons, we moved some of the insert logic up to the
> application level in our product.
Yeah, I think the key there would be to produce a function that wrote
the function for you.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)