Re: Truncate Triggers - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Truncate Triggers
Date
Msg-id 1201375323.4257.598.camel@ebony.site
Whole thread Raw
In response to Re: Truncate Triggers  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-hackers
On Sat, 2008-01-26 at 11:19 -0500, Robert Treat wrote:
> On Friday 25 January 2008 06:40, Simon Riggs wrote:
> > 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.]
> >
> 
> This seems to completly hand-wave away the idea of implementing row level 
> visibility in statement level triggers, something I am hoping to see 
> implemented somewhere down the line. Am I missing something?

Not sure why you say that.

We have a choice:
i) TRUNCATE never has access to rows
ii) TRUNCATE can have access, in which case it acts like a DELETE

Forcing ii) in all cases would effectively negate truncate triggers, so
we must have some way of providing both alternatives as options. 

As Chris explained, if we allow a BEFORE STATEMENT trigger on TRUNCATE
to issue a DELETE instead, then we are OK to just allow i) and yet
retain the ability to access rows for those that want it. There may be
another of way of doing this also, but I'll leave that possibility to
whoever tries to implement the feature you mention in the future.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Truncate Triggers
Next
From: Ivan Voras
Date:
Subject: Re: Simple row serialization?