On 11/24/2013 06:42 AM, Simon Riggs wrote:
I think we should be thinking harder about how to implement
ASSERTIONs, possibly calling them ASSERTION TRIGGERs not pre-commit
write event triggers.
I don't know that anyone is working on this, though, or even plans to.
--
Josh Berkus
PostgreSQL
On 11/24/2013 09:42 AM, Simon Riggs wrote:
It looks to me that this idea is horribly physical and seems likely to
be badly misused.
I don't see any way to use these that won't be quite ugly. There is no
trigger descriptor, so no way of writing a constraint sensibly, since
you'll need to make
Josh Berkus j...@agliodbs.com writes:
On 11/24/2013 06:42 AM, Simon Riggs wrote:
I think we should be thinking harder about how to implement
ASSERTIONs, possibly calling them ASSERTION TRIGGERs not pre-commit
write event triggers.
I don't know that anyone is working on this, though, or even
Andrew Dunstan and...@dunslane.net writes:
Write a hack is not normally advice I like to give or receive.
We're after a feature that at least one other RDBMS that we know of suports.
But leaving that aside, what are the restrictions, if any, in what can
be done in such a callback? Are we
On 11/26/2013 09:45 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 11/24/2013 06:42 AM, Simon Riggs wrote:
I think we should be thinking harder about how to implement
ASSERTIONs, possibly calling them ASSERTION TRIGGERs not pre-commit
write event triggers.
I don't know that
On 11/26/2013 01:04 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Write a hack is not normally advice I like to give or receive.
We're after a feature that at least one other RDBMS that we know of suports.
But leaving that aside, what are the restrictions, if any, in what can
On 19 November 2013 16:46, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 19, 2013 at 12:45 AM, Noah Misch n...@leadboat.com wrote:
On Fri, Nov 15, 2013 at 01:01:48PM -0500, Andrew Dunstan wrote:
The triggers don't fire if there is no real XID, so only actual data
changes should cause
On 11/19/2013 12:45 AM, Noah Misch wrote:
On Fri, Nov 15, 2013 at 01:01:48PM -0500, Andrew Dunstan wrote:
The triggers don't fire if there is no real XID, so only actual data
changes should cause the trigger to fire.
What's the advantage of this provision? Without it, an individual trigger
On Tue, Nov 19, 2013 at 08:54:49AM -0500, Andrew Dunstan wrote:
On 11/19/2013 12:45 AM, Noah Misch wrote:
On Fri, Nov 15, 2013 at 01:01:48PM -0500, Andrew Dunstan wrote:
The triggers don't fire if there is no real XID, so only actual data
changes should cause the trigger to fire.
What's the
Hi,
On 2013-11-15 13:01:48 -0500, Andrew Dunstan wrote:
Attached is a patch to provide a new event trigger that will fire on
transaction commit. I have tried to make certain that it fires at a
sufficiently early stage in the commit process that some of the evils
mentioned in previous
On Tue, Nov 19, 2013 at 12:45 AM, Noah Misch n...@leadboat.com wrote:
On Fri, Nov 15, 2013 at 01:01:48PM -0500, Andrew Dunstan wrote:
The triggers don't fire if there is no real XID, so only actual data
changes should cause the trigger to fire.
What's the advantage of this provision? Without
Andrew Dunstan and...@dunslane.net writes:
Perhaps my understanding of when XIDs are acquired is insufficient. When
exactly is it optional?
My understanding of Noah's comment is that we would be exposing what
used to be an optimisation only implementation detail to the user, and
so we would
On 11/19/2013 08:42 AM, Andres Freund wrote:
Could you explain a bit what the use case of this is and why it's not
sufficient to allow constraint triggers to work on a statement level?
Just that there would be multiple ones fired?
The main reason is to enforce arbitrary assertions which need
On 2013-11-19 12:45:27 -0800, Josh Berkus wrote:
On 11/19/2013 08:42 AM, Andres Freund wrote:
Could you explain a bit what the use case of this is and why it's not
sufficient to allow constraint triggers to work on a statement level?
Just that there would be multiple ones fired?
The main
On 11/19/2013 03:54 PM, Andres Freund wrote:
On 2013-11-19 12:45:27 -0800, Josh Berkus wrote:
On 11/19/2013 08:42 AM, Andres Freund wrote:
Could you explain a bit what the use case of this is and why it's not
sufficient to allow constraint triggers to work on a statement level?
Just that
On 2013-11-19 16:04:12 -0500, Andrew Dunstan wrote:
On 11/19/2013 03:54 PM, Andres Freund wrote:
On 2013-11-19 12:45:27 -0800, Josh Berkus wrote:
On 11/19/2013 08:42 AM, Andres Freund wrote:
Could you explain a bit what the use case of this is and why it's not
sufficient to allow constraint
On 11/19/2013 04:23 PM, Andres Freund wrote:
On 2013-11-19 16:04:12 -0500, Andrew Dunstan wrote:
On 11/19/2013 03:54 PM, Andres Freund wrote:
On 2013-11-19 12:45:27 -0800, Josh Berkus wrote:
On 11/19/2013 08:42 AM, Andres Freund wrote:
Could you explain a bit what the use case of this is
On Fri, Nov 15, 2013 at 01:01:48PM -0500, Andrew Dunstan wrote:
The triggers don't fire if there is no real XID, so only actual data
changes should cause the trigger to fire.
What's the advantage of this provision? Without it, an individual trigger
could make the same check and drop out
On 11/17/2013 01:42 AM, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
I have not looked at the patch, but does it also run pre-rollback ?
error in trigger - instant infinite loop.
Means this needs to have some kind of recursion depth limit, like python
def x():
... return
Hannu Krosing wrote:
So it would send a network message, a signal or writing something to
external file.
If you're OK with a C function, you could try registering a callback,
see RegisterXactCallback().
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On 11/17/2013 04:20 PM, Alvaro Herrera wrote:
Hannu Krosing wrote:
So it would send a network message, a signal or writing something to
external file.
If you're OK with a C function, you could try registering a callback,
see RegisterXactCallback().
I already have an implementation doing
On 2013-11-17 09:39:26 +0100, Hannu Krosing wrote:
Besides, exactly what would you do in such a trigger?
The use case would be telling another system about the rollback.
Basically sending a ignore what I told you to do message
But you can't rely on it - if e.g. the server
On 11/17/2013 07:31 PM, Andres Freund wrote:
On 2013-11-17 09:39:26 +0100, Hannu Krosing wrote:
Besides, exactly what would you do in such a trigger?
The use case would be telling another system about the rollback.
Basically sending a ignore what I told you to do message
But you can't rely
On 11/15/2013 07:01 PM, Andrew Dunstan wrote:
Attached is a patch to provide a new event trigger that will fire on
transaction commit. I have tried to make certain that it fires at a
sufficiently early stage in the commit process that some of the evils
mentioned in previous discussions on
On 11/16/2013 03:00 PM, Hannu Krosing wrote:
On 11/15/2013 07:01 PM, Andrew Dunstan wrote:
Attached is a patch to provide a new event trigger that will fire on
transaction commit. I have tried to make certain that it fires at a
sufficiently early stage in the commit process that some of the
Hannu Krosing ha...@2ndquadrant.com writes:
I have not looked at the patch, but does it also run pre-rollback ?
error in trigger - instant infinite loop.
Besides, exactly what would you do in such a trigger? Not modify
the database, for certain, because we're about to roll back.
Attached is a patch to provide a new event trigger that will fire on
transaction commit. I have tried to make certain that it fires at a
sufficiently early stage in the commit process that some of the evils
mentioned in previous discussions on this topic aren't relevant.
The triggers don't
On Fri, 2013-11-15 at 13:01 -0500, Andrew Dunstan wrote:
Attached is a patch to provide a new event trigger that will fire on
transaction commit.
xact.c: In function ‘CommitTransaction’:
xact.c:1835:3: warning: implicit declaration of function
‘PreCommitTriggersFire’
On 11/15/2013 09:07 PM, Peter Eisentraut wrote:
On Fri, 2013-11-15 at 13:01 -0500, Andrew Dunstan wrote:
Attached is a patch to provide a new event trigger that will fire on
transaction commit.
xact.c: In function ‘CommitTransaction’:
xact.c:1835:3: warning: implicit declaration of function
29 matches
Mail list logo
