Re: Truncate Triggers

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Truncate Triggers
Date: 2008-01-26 19:22:03
Message-ID: 1201375323.4257.598.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ivan Voras 2008-01-26 19:40:46 Re: Simple row serialization?
Previous Message Tom Lane 2008-01-26 19:16:25 Re: Truncate Triggers