Re: Precedence of a TRIGGER vs. a CHECK on a column

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: ezra epstein <ee_newsgroup_post(at)prajnait(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Precedence of a TRIGGER vs. a CHECK on a column
Date: 2004-01-19 20:27:32
Message-ID: 10219.1074544052@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> I think it's that your domain constraint is being applied before the
> trigger is executed and that the table constraints are being applied
> after given that I get the same behavior with a domain constraint of not
> null. This makes sense (although I haven't checking the spec wording)
> since the value is being coerced into the domain in order to be put into
> the row that's being passed to the trigger (thus triggering the domain
> constraints).

IIRC other datatype-related constraints, such as max length for a
char(n) or varchar(n) column, are also checked before triggers are
fired. We have had complaints about that before, mainly from people
who wanted to use a trigger to truncate a varchar value before the
constraint gets checked.

I think this ordering of operations is largely an implementation
artifact and could in theory be changed, but I'm disinclined to change
it unless someone can show that the spec requires different behavior.
In particular, ISTM that if we change it, the input to the trigger
wouldn't really be a legal value of the table's rowtype.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message bill.postgresql-users 2004-01-19 22:15:00 Re: 7.4 -> 7.4.1 upgrade with customization on freebsd
Previous Message scott.marlowe 2004-01-19 20:27:13 Re: New PostgreSQL search resource