Thinking hard about wording...
Add partially implemented FOR EACH STATEMENT statement-level triggers (Neil Conway)
which doesn't look nice but expresses what's implemented. Taken from the
CREATE TRIGGER FOR EACH STATEMENT documentation, a user would think he
could do the same stuff as on lets say MSSQL, in a way known from
row-level triggers. The example trigger-example.html seems to be
non-statement-level trigger aware. Chapter 37 is quite misleading, for
example recursive triggers are mentioned "programmer's responsibility to
avoid infinite recursion"suggesting there would be a way to know about
the affected rows...
Actually, I'd consider not to mention statement triggers at all. In the
current state, they will provoke some annoyance if people try to use
them. We will see them on the mailing lists, seeking for what's
currently not available...
Regards,
Andreas
Bruce Momjian wrote:
>Do you have suggested wording?
>
>---------------------------------------------------------------------------
>
>Andreas Pflug wrote:
>
>
>>Bruce Momjian wrote:
>>
>>
>>
>>>Here are the changes for 7.4. I am looking for any improvements. This
>>>will be adjusted as we move through beta.
>>>
>>>---------------------------------------------------------------------------
>>>Add FOR EACH STATEMENT statement-level triggers (Neil Conway)
>>>
>>>
>>>
>>AFAICS the current implementation still doesn't have a way to access the
>>affected rowset, so it'a pretty much like a SELECT without a WHERE. This
>>restricts the usability of statement-level triggers to very limited
>>cases. IMHO it's not a good idea to announce an incompletely implemented
>>feature.
>>
