Re: Order of evaluation in triggers for checks on inherited table partitions - Mailing list pgsql-sql

From Jasen Betts
Subject Re: Order of evaluation in triggers for checks on inherited table partitions
Date
Msg-id irvnif$o8n$4@reversiblemaps.ath.cx
Whole thread Raw
In response to Order of evaluation in triggers for checks on inherited table partitions  (Kevin Crain <kevin.crain1@gmail.com>)
Responses Re: Re: Order of evaluation in triggers for checks on inherited table partitions  (Kevin Crain <kevin.crain1@gmail.com>)
List pgsql-sql
On 2011-05-27, Kevin Crain <kevin.crain1@gmail.com> wrote:
> I am trying to create a trigger on updates to a table that is
> partitioned.  The child tables are partitioned by month and include
> checks on a timestamp field. 

> However when I try to update an existing record with a
> timestamp that would place it in a child table different from the
> child table it is in I get an error due to the check on the child
> table it is currently in.  My best guess as to what is happening is
> that the trigger is evaluating the check before it evaluates the
> trigger function and thus cannot tell that the update to the original
> table should never take place.  I have included an example below.  The
> error that results is "new row for relation "t_foo_2011_6" violates
> check constraint "t_foo_2011_6_f_timestamp_check""

the problem is the check is running before the trigger.
perhaps you can use a rule instead of a trigger?

-- 
⚂⚃ 100% natural



pgsql-sql by date:

Previous
From: Surfing
Date:
Subject: Function to total reset a schema
Next
From: Kevin Crain
Date:
Subject: Re: Re: Order of evaluation in triggers for checks on inherited table partitions