Re: AW: [HACKERS] Rule system

From: jwieck(at)debis(dot)com (Jan Wieck)
To: andreas(dot)zeugswetter(at)telecom(dot)at (Andreas Zeugswetter)
Cc: pgsql-hackers(at)postgreSQL(dot)org, jwieck(at)debis(dot)com
Subject: Re: AW: [HACKERS] Rule system
Date: 1998-08-12 11:51:09
Message-ID: m0z6ZQs-000EBPC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> 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(at)debis(dot)com (Jan Wieck) #

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Herouth Maoz 1998-08-12 12:25:39 Re: [SQL] Query based on date/time field
Previous Message Maarten Boekhold 1998-08-12 11:01:28 Re: [HACKERS] 6.3.2. patch for functional indices