Re: Truncate Triggers

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Truncate Triggers
Date: 2008-01-25 18:50:15
Message-ID: 1201287015.4257.486.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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?

We can alter the API for triggers to do that. Or are you thinking of
having the Truncate Trigger API be different?

> > I also plan to add a TRUNCATE privilege, though that will be a separate
> > patch in a later post. That will widen the use case of TRUNCATE, which
> > should be OK to do once we've covered the replication concerns.
>
> Considering it's not MVCC-safe, do we *want* to widen the use case?
>
> There are way too many table privilege bits already; to add more you
> need something a lot stronger than a "might be nice" argument.

People use TRUNCATE whatever we say. If you force people to be table
owners or superusers you merely restrict their security options.

If you want to prevent wider use then perhaps a better explanation of
what "MVCC-safe" means in the docs would do that. Most people don't
understand that phrase, or its implications.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-01-25 18:54:36 Re: Proposal: Integrity check
Previous Message Tom Lane 2008-01-25 18:49:54 Re: Thoughts about bug #3883