>
> Jan Wieck wrote:
> > What else must be there? I think everything on the instance
> > level is better done by triggers. And if we add
> > row-/statement-level triggers on SELECT, there would be no
> > reason left to have non-instead rules. Or am I missing
> > something?
> While this is in my opinion true, it would be nice to extend the trigger syntax to
> allow the triggered action to be expressed in sql like:
>
> create trigger blabla after delete on people
> referencing old as o
> (insert into graves values (o.*)); -- disregard the syntax
>
> Andreas
With PL/pgSQL I can actually do the following:
create function on_death() returns opaque as '
begin
insert into graves (name, born, died)
values (old.name, old.born, ''now'');
return old;
end;
' language 'plpgsql';
create trigger on_death after delete on people
for each row execute procedure on_death();
I think we could extend the parser that it accepts the above
syntax and internally creates the required trigger procedure
and the trigger itself in the way we treat triggers now. This
is the same way we actually deal with views (accept create
view but do create table and create rule internally).
It would require two extensions to PL/pgSQL:
A 'RENAME oldname newname' in the declarations part so
the internal trigger procedures record 'old' can be
renamed to 'o'.
Implementation of referencing record/rowtype.* extends to
a comma separated list of parameters when manipulating
the insert statement. My current implementation of
PL/pgSQL can only substitute a single
variable/recordfiled/rowfield into one parameter.
These two wouldn't be that complicated. And it would have a
real advantage. As you see above, I must double any ' because
the function body is written inside of ''s. It's a pain - and
here's a solution to get out of it.
If anyone is happy with this, I would release PL/pgSQL after
6.4 and make the required changes in the parser.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
