From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Truncate Triggers |
Date: | 2008-01-25 15:44:19 |
Message-ID: | 690.1201275859@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Wes | 2008-01-25 16:14:04 | Re: REINDEX on large DB vs. DROP INDEX/CREATE INDEX |
Previous Message | Andrew Dunstan | 2008-01-25 15:11:49 | Re: plperl: Documentation on BYTEA decoding is wrong |