On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org