![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
|
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) VALUES ('11:1999'); ERROR: invalid input syntax for type date: "15.11:1999" CONTEXT: PL/pgSQL function "function_test_reg1" line 12 at assignment retrovirology=# This values do pass NOW the CHECK CONSTRAINT ???? and are injected in the trigger function. Normally the trigger shouldn't m have an influence an the CHECK CONSTRAINT. |
#2
| |||
| |||
|
|
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. |
#3
| |||
| |||
|
|
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. =20 If you want, say, a varchar length constraint to be checked only after the trigger runs, I'd counsel declaring the column as plain text and writing the length test as a CHECK constraint. |
![]() |
| Thread Tools | |
| Display Modes | |
| |