Re: delta relations in AFTER triggers

2014-07-29 9:41 GMT+02:00 Marti Raudsepp <marti(at)juffo(dot)org>:

> On Tue, Jul 29, 2014 at 9:49 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > I dislike this proposal - it is strongly inconsistent with current
> trigger
> > design
>
> The real point I was trying to convey (in my previous email) is that
> these declarations should be part of the trigger *function* not the
> function-to-table relationship. CREATE TRIGGER shouldn't be in the
> business of declaring new local variables for the trigger function.
> Whether we define new syntax for that or re-use the argument list is
> secondary.
>
> But the inconsistency is deliberate, I find the current trigger API
> horrible. Magic variables... Text-only TG_ARGV for arguments...
> RETURNS trigger...
>

A notation RETURNS TRIGGER I don't like too much too - RETURNS void or
RETURNS record are much more natural.

My dream is some like CREATE OR REPLACE TRIGGER FUNCTION trg() RETURNS
RECORD

but it is only syntactic sugar - and I don't see any benefit why we should
to implement it.

> No way to invoke trigger functions directly for
> testing.
>

It is horrible idea. I can agree, it is a limit - but not too hard - there
is simple possibility to take code from trigger to auxiliary function. But
current design is simply and robust with few possible user errors.

>
> By not imitating past mistakes, maybe we can eventually arrive at a
> language that makes sense.
>

Sorry I disagree. Can be subjective is this API is too or not too bad for
redesign. More objective arguments - there are no performance issue, no
security issue. I am thinking, so it has sense, so I don't see reason why
to change it and why we should to have two API. Last argument, if we change
something, then we should to use a ANSI SQL syntax everywhere it is
possible (when we don't get any new special functionality).

Regards

Pavel

>
> Regards,
> Marti
>