Andreas Joppich wrote:
>
> Hi all,
>
> at work I=B4m using RDB 6.2. I can create triggers with the following
> command:
>
> AFTER UPDATE OF
> SIM_ICCV_L,
> SIM_ICCNR_L,
> START_DATUM_D,
> STAT_SEIT_D,
> PREISKLASSE_T
> ON ent_TEILNEHMER REFERENCING OLD AS update_old NEW AS update_new
> ( UPDATE ent_TEILNEHMER t
> SET t.update_l =3D update_old.update_l + 1,
> t.insert_datum_d =3D cast(current_timestamp as date)
> WHERE ent_TEILNEHMER.dbkey =3D t.dbkey )
> FOR EACH ROW;
>
> or:
>
> AFTER INSERT ON ent_TEILNEHMER
> (UPDATE ent_TEILNEHMER t
> SET t.update_l =3D 1,
> t.insert_datum_d =3D cast(current_timestamp as date)
> WHERE ent_TEILNEHMER.dbkey =3D t.dbkey)
> FOR EACH ROW;
>
> With postgresql 6.2 or 6.3 I must use a user defined function to get the
> same result. =
>
>
> Will there be some enhancements to triggers to use the above syntax ? I
> think, RDB is more user friendly ( at least for trigger defintions)...
Now that 6.3 is out, I'm beginning with PL/pgSQL. It will not
cover the above exactly, but it will allow an SQL like
procedural language to be used to create the trigger
procedures so you don't have to write the triggers in 'C'. In
the meantime you might want to take a look into src/pl/tcl
where you'll find Tcl as a loadable PL that can do it for
you.
If PL/pgSQL get's ready someday, I'll take a look at the
parser if we can enhance it to accept the above syntax and
automagically create an appropriate trigger procedure.
Until later, 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) #
