Robert Haas wrote:
> Not this patch's problem directly, but while scrutinizing this it
> crossed my mind that we would need to prohibit constraint triggers
> with transition tables. It turns out that we do, in the parser:
>
> create constraint trigger table2_trig
> after insert on table2 referencing new table as new_table
> for each statement execute procedure dump_insert();
> ERROR: syntax error at or near "referencing"
>
> Possibly it would be better to allow the syntax and error out in
> CreateTrigger(), so that we can give a better error message. It's
> certainly not obvious from the syntax summary produced by \h CREATE
> TRIGGER why this doesn't work.
Yeah, I agree. This doesn't look like actual protection, but just a
"happy accident", and the syntax error message is not helpful either.
We could keep it very simple by just throwing the error right there in
gram.y's production, adding TriggerReferencing in the right place in the
CREATE CONSTRAINT TRIGGER production -- at this stage there doesn't seem
to be a need to expand this any further.
> This might be more future-proof, too,
> if somebody someday adds support for REFERENCING { OLD | NEW } ROW to
> constraint triggers and fails to realize that there's not a check
> anywhere outside the parser for the table case.
I suppose in the future it would make sense to allow for-each-statement
constraint triggers with transition tables. It'd probably a useful way
to optimize FK checks for bulk operations.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services