On Mon, May 2, 2022 at 6:33 PM Josh Silver <josh.ag@paladin.insure> wrote:
And, given the existing length and depth of content of that page already I'm doubtful that introducing the corner-case of UPDATE OF (col) into that section, in the level of detail provided in CREATE TRIGGER, is a net positive.
I'd definitely lean towards complete over terse, especially since I don't think it's any more detailed or lengthy than the WHEN CLAUSE that's already there, but given those concerns I think at a minimum mentioning column specific triggers by name and that changes made to the row's contents by BEFORE UPDATE triggers are not considered.
I'd probably leave the detail where it is, note that "UPDATE OF (col)" exists as a distinct event type that modifies a plain UPDATE TRIGGER's event check, and direct the reader to the specifics in CREATE TRIGGER should they feel the need to use the more specific form.
That sounds reasonable to me, What about splitting column specific triggers up across the page, so that less space is given to them? Something like
These two types of triggers are sometimes called row-level triggers and statement-level triggers, respectively. <NEW>A row-level trigger that specifies a list of columns is a column-specific trigger.</NEW> Triggers on TRUNCATE may only be defined at statement level, not per-row.
If more than one trigger is defined for the same event on the same relation, the triggers will be fired in alphabetical order by trigger name. In the case of BEFORE and INSTEAD OF triggers, the possibly-modified row returned by each trigger becomes the input to the next trigger. <NEW>Changes made to the row's contents by BEFORE UPDATE triggers do not change which column specific triggers will be fired, because they only consider whether any of its columns are listed as targets in the UPDATE command's SET list.</NEW> If any BEFORE or INSTEAD OF trigger returns NULL, the operation is abandoned for that row and subsequent triggers are not fired (for that row).
It saves the syntax for the SQL command page, and it trades directing the users to the SQL page for describing the behavior. The overview page already has a link to the SQL command page, so it saves having to re-mention it.
