>> But then again, even if functions stay that restricted, what
>> do we need as rule functionality? Up to now I only have all
>> kinds of INSTEAD rules on the statement level on my list.
>
>The [select] trigger can't return sets/tuples or multiple rows the select rule system can.
>This is because of the currently restricted "create function" return values.
>
>I'll try to look over my diploma paper tonight, to look for rules that (at least currently)
>cannot be written as triggers (other than instead rules).
Ok, I did not find anything (I tried hard) :-). Especially nothing that would currently work.
(I know more of it did work in postgres 4.2 though :-( )
So I really think the insert/update/delete rules, other than the instead stuff of course, are oblivious,
and don't work properly anyways, so we could probably really nuke them.
Not the select rules of course !
I still think the trigger syntax should be extended to allow a block of sql, like in Informix.
Then you could: execute one or more procedures, or as in most cases
do a simple statement like cascade a delete. Also a syntax would be nice
that would allow to change the "new" tuple.
In Informix the block begins with a ( and ends with ), the statements are separated by commas:
(insert into log values ('insert', new.name),
execute procedure current_datetime() into new.lastupdate)
While I dont particularly like the syntax it does provide excellent functionality.
Andreas
