Nikhil Sontakke wrote:
> A similar DELETE trigger should be pretty easy to write up in C. I
> think the main challenge is with UPDATE triggers especially if the new
> row will fall into another child table - but we can always throw an
> error for such a case initially.
I agree. A first implementation could be restricted to updates within
the same partition.
>
> Right now if the row cannot be inserted in any child table, it is
> inserted in the parent. If you want to fail, we can add a 'fail
> trigger' (after all other triggers) that generates an error if
> previous triggers did not capture the row. If you want to create a
> new partition, you can have another trigger to handle that.
>
>
> One of the work items related to partitioning eventually is to avoid
> having to APPEND the parent in all queries involving children. Maybe
> having an overflow child table might help to catch failed triggers for
> those cases?
This is a good option too.
Emmanuel
>
> Regards,
> Nikhils
>
>
>
> So I think that this trigger approach is pretty flexible like
> people used AOP in J2EE servers to process requests. It has also
> the advantage of allowing fast prototyping. It should also be easy
> to push that functionality down in the core as needed.
>
> Is it ok if I move Simon's requirement document under a more
> generic 'Table partitioning' page on the Wiki?
>
> Thanks for your feedback,
> manu
>
>
> Jaime Casanova wrote:
>
> On Mon, Dec 15, 2008 at 1:46 PM, Gregory Stark
> <stark@enterprisedb.com <mailto:stark@enterprisedb.com>> wrote:
>
>
> Josh Berkus <josh@agliodbs.com <mailto:josh@agliodbs.com>>
> writes:
>
>
>
> Hackers,
>
> We don't yet seem to have a clear specification for
> this feature, and the Other
> Open Source DB has shown us how problematic it is to
> get auto-partitioning
> wrong.
>
> Should we defer auto-partitioning to 8.5?
>
>
> If we're serious about having a "next generation"
> partitioning with a concept
> of partition keys then it seems to me to make more sense
> to do that first and
> then add on a feature like this.
>
>
>
>
> +1
>
>
>
> This is still very useful. I haven't looked at the actual
> patch, does it
> require core changes or can it be stashed in a pgfoundry
> or contrib module?
>
>
>
>
> what i don't like about this one is that it creates partitions at
> create table time and to manually add all new partitions (inherit
> tables and modify the trigger)... and what i want to see is an
> automatic creation when it's needed...
>