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
<st...@enterprisedb.com <mailto:st...@enterprisedb.com>> wrote:
Josh Berkus <j...@agliodbs.com <mailto:j...@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...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
