> I don't see any bug here; it's just that CHECK constraints are applied
> after any BEFORE triggers are run. Since the triggers could change the
> data to be inserted, the reverse order would be insecure.
Ups, it did make some false assumptions.
Thank you for the clarification.
If I understo
> Correct. It is annoying in some cases, but if the input to the trigger
> isn't of the column datatype, then what type is it? It's hard to see
> how that could work in general.
>
> If you want, say, a varchar length constraint to be checked only after
> the trigger runs, I'd counsel declaring t
On Tue, 10 Feb 2004, Daniel Struck wrote:
> retrovirology=# INSERT INTO test_reg1 (date_user) VALUES ('111.1999');
> ERROR: invalid input syntax for type date: "111.1999"
> CONTEXT: PL/pgSQL function "function_test_reg1" line 8 at assignment
> retrovirology=# INSERT INTO test_reg1 (date_user) VA
Daniel Struck <[EMAIL PROTECTED]> writes:
> This makes it also impossible to change the type of a value by a trigger?
Correct. It is annoying in some cases, but if the input to the trigger
isn't of the column datatype, then what type is it? It's hard to see
how that could work in general.
If yo
Daniel Struck <[EMAIL PROTECTED]> writes:
> I think I have found a bug in postgresql:
I don't see any bug here; it's just that CHECK constraints are applied
after any BEFORE triggers are run. Since the triggers could change the
data to be inserted, the reverse order would be insecure.