On 11/15/2012 03:44 PM, Darren Duncan wrote:
As they currently exist, triggers always fire based on certain SQL
syntax used, rather than on the semantics of what is actually going on.
That's not quite right. COPY fires INSERT triggers, despite never using
an explicit INSERT statement. There
A row-level trigger for TRUNCATE does not really make sense, as it would
mean that TRUNCATE needs to scan each tuple of the table it needs to
interact with to fire its trigger, so it would more or less achieve the
same performance as a plain DELETE FROM table;.
TRUNCATE is performant because it
On 11/15/2012 09:48 AM, Craig Ringer wrote:
If you want to prevent TRUNCATE, deny the privilege or add a trigger
that aborts the command.
You can abort the transaction but not skip action as currently it is only
possible to skip in ROW level triggers.
So I'd modify this request to allow BEFORE
On 11/15/2012 06:25 PM, Hannu Krosing wrote:
On 11/15/2012 09:48 AM, Craig Ringer wrote:
If you want to prevent TRUNCATE, deny the privilege or add a trigger
that aborts the command.
You can abort the transaction but not skip action as currently it is only
possible to skip in ROW level
Craig Ringer wrote:
On 11/15/2012 06:25 PM, Hannu Krosing wrote:
On 11/15/2012 09:48 AM, Craig Ringer wrote:
If you want to prevent TRUNCATE, deny the privilege or add a trigger
that aborts the command.
You can abort the transaction but not skip action as currently it is only
possible to skip
On Thu, Nov 15, 2012 at 2:53 PM, Darren Duncan dar...@darrenduncan.net
wrote:
I still think the syntax of TRUNCATE FOR EACH ROW would be useful, but if
no one agrees...
I'm compelled to disagree.
What was useful about TRUNCATE in the first place was that it quickly
operated against the entire
Darren Duncan dar...@darrenduncan.net writes:
So, I'm partly proposing a specific narrow new feature, TRUNCATE FOR EACH
ROW
Kevin has been proposing that we consider an alternative approach in
some other cases that I think would work better for you, too. Namely, to
have access to OLD and NEW in
Dimitri Fontaine wrote:
Darren Duncan dar...@darrenduncan.net writes:
So, I'm partly proposing a specific narrow new feature, TRUNCATE FOR EACH
ROW
Kevin has been proposing that we consider an alternative approach in
some other cases that I think would work better for you, too. Namely, to
On 11/16/2012 05:38 AM, Dimitri Fontaine wrote:
Darren Duncan dar...@darrenduncan.net writes:
So, I'm partly proposing a specific narrow new feature, TRUNCATE FOR EACH
ROW
Kevin has been proposing that we consider an alternative approach in
some other cases that I think would work better for
On Fri, Nov 16, 2012 at 6:38 AM, Dimitri Fontaine dimi...@2ndquadrant.frwrote:
Darren Duncan dar...@darrenduncan.net writes:
So, I'm partly proposing a specific narrow new feature, TRUNCATE FOR
EACH
ROW
Kevin has been proposing that we consider an alternative approach in
some other cases
On 15 November 2012 05:25, Hannu Krosing ha...@2ndquadrant.com wrote:
On 11/15/2012 09:48 AM, Craig Ringer wrote:
If you want to prevent TRUNCATE, deny the privilege or add a trigger
that aborts the command.
You can abort the transaction but not skip action as currently it is only
possible
I have a feature request, which at one level should require little code change,
but at another level may require more.
Since Postgres 9.3 is going to be doing some significant feature additions for
triggers, I'd like to see some more.
As they currently exist, triggers always fire based on
12 matches
Mail list logo
