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: | 19670.1238518538@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2009-03-31 17:02:34 | Re: Solaris getopt_long and PostgreSQL |
Previous Message | Euler Taveira de Oliveira | 2009-03-31 16:55:02 | Re: can't load plpython |