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

Re: Partitioning feature ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Emmanuel Cecchet <manu(at)asterdata(dot)com>
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:55:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Emmanuel Cecchet <manu(at)asterdata(dot)com> writes:
> 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.

[ shrug... ]  Badly written user triggers can break FK constraints,
too.  We've tolerated that in the past because preventing it disables
useful capabilities.

I remain of the opinion that if you think you *have to* execute last,
you should not be writing this as a trigger; you'd be better off
embedding it lower in the system.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Zdenek KotalaDate: 2009-03-31 17:02:34
Subject: Re: Solaris getopt_long and PostgreSQL
Previous:From: Euler Taveira de OliveiraDate: 2009-03-31 16:55:02
Subject: Re: can't load plpython

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