Re: Order of evaluation in triggers for checks on inherited table partitions
От | Jasen Betts |
---|---|
Тема | Re: Order of evaluation in triggers for checks on inherited table partitions |
Дата | |
Msg-id | irvnif$o8n$4@reversiblemaps.ath.cx обсуждение исходный текст |
Ответ на | Order of evaluation in triggers for checks on inherited table partitions (Kevin Crain <kevin.crain1@gmail.com>) |
Ответы |
Re: Re: Order of evaluation in triggers for checks on inherited
table partitions
|
Список | 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 по дате отправления: