Skip site navigation (1) Skip section navigation (2)

Re: Partitioning feature ...

From: Emmanuel Cecchet <manu(at)asterdata(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Nikhil Sontakke<nikhil(dot)sontakke(at)enterprisedb(dot)com>, Jaime Casanova<jcasanov(at)systemguards(dot)com(dot)ec>, Kedar Potdar <kedar(dot)potdar(at)gmail(dot)com>,Emmanuel Cecchet <Emmanuel(dot)Cecchet(at)asterdata(dot)com>,"pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Amit Gupta<amit(dot)pc(dot)gupta(at)gmail(dot)com>
Subject: Re: Partitioning feature ...
Date: 2009-03-31 16:45:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Yes, there is a good reason. As a trigger can update the tuple value, 
this can change the routing decision. If you have a user trigger that 
tries to change the key value after the partition choice has been made, 
this will lead to an integrity constraint violation which is probably 
not what the user expects.
Note that user triggers with partitions will be tricky anyway 
(regardless of how partitioning is implemented, that is with triggers or 
not). If 2 partitions have user triggers that update the key value to 
bounce the tuple to the other partition you may end up with an infinite 
I am not sure what the semantic of statement triggers (still user 
triggers) should be on partitioned tables.
We will probably have to come up with restrictions on triggers so that 
they can only be applied to the parent table and not on child tables to 
prevent nasty issues.


Tom Lane wrote:
> In the case of the FK triggers, it's intentional (and maybe even
> documented) that users should be able to place their own triggers before
> or after the FK triggers.  Is there a good reason why partitioning
> triggers should be different?  If there is, maybe the feature shouldn't
> be implemented via triggers in the first place.
>                         regards, tom lane

Emmanuel Cecchet
Aster Data Systems

In response to


pgsql-hackers by date

Next:From: justinDate: 2009-03-31 16:48:54
Subject: Re: [HACKERS] string_to_array with empty input
Previous:From: Tom LaneDate: 2009-03-31 16:21:52
Subject: Re: Solaris getopt_long and PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group