Re: Release changes

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.
>>