On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > Notes: As the syntax shows, these would be statement-level triggers
> > (only). Requesting row level triggers will cause an error. [As Chris
> > Browne explained, if people really want, they can use these facilities
> > to create a Before Statement trigger that executes a DELETE, which then
> > fires row level calls.]
>
> Is there a way for a BS trigger to return a flag "skip the statement",
> as there is for BR?
I've got a working version of truncate triggers now, posted to -patches
shortly.
Answering the above question is the last point of the implementation.
ISTM it would be best to think of it as a separate and not-very related
feature, implemented as a separate patch, if we decide we really do want
that. It doesn't seem important to do that for replication, which was
the main use case for truncate triggers.
Currently, BS trigger functions return NULL. This is handled in various
ways within each PL and is specifically tested for within main trigger
exec code. Returning different information in some form or other would
be required to signal "skip the main statement". FOR EACH ROW triggers
return NULL when they want to skip the change for that row, so the
current implementation is the wrong way round for BS triggers. I'm not
sure how to handle that in a way that makes obvious sense for future
trigger developers, so suggestions welcome.
So allowing us to skip commands as a result of statement level triggers
is as much work for INSERT, UPDATE, DELETE and TRUNCATE together as it
is just for TRUNCATE. I also think that if we did do that for TRUNCATE
it would be useful to do for the other commands anyway. SQLStandard
doesn't say we *can't* do this.
Having said that, some PLs simply ignore the return value from BS
triggers. So interpreting return values in new ways might make existing
trigger code break or behave differently. So if we did BS trigger
skipping for all statement types then we would need to introduce that
concept slowly over a couple of releases with a non-default, then
default trigger behaviour parameter.
I've written the truncate trigger handling in such a way that it would
be straightforward to extend this to include statement skipping, should
we do it in the future.
Can we just skip statement skipping?
-- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com