Re: Truncate Triggers

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Truncate Triggers
Дата
Msg-id 1201287015.4257.486.camel@ebony.site
обсуждение исходный текст
Ответ на Re: Truncate Triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Truncate Triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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?

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zdenek Kotala
Дата:
Сообщение: Re: Proposal: Integrity check
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Thoughts about bug #3883