Re: Clarification of triggers with 'OF column_name' in 'Overview of Trigger Behavior'

On Mon, May 2, 2022 at 7:11 PM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Mon, May 2, 2022 at 6:55 PM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>> On Mon, May 2, 2022 at 6:33 PM Josh Silver <josh(dot)ag(at)paladin(dot)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.

Josh