On 11/26/2013 01:04 PM, Tom Lane wrote:
Andrew Dunstan 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
On 11/26/2013 09:45 AM, Tom Lane wrote:
> Josh Berkus 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 anyo
Andrew Dunstan 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 allowed to alter
Josh Berkus 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 plans to.
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 a
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 19 November 2013 16:46, Robert Haas wrote:
> On Tue, Nov 19, 2013 at 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'
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 and
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 al
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 the
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?
>
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 ne
Andrew Dunstan 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 need to properly docu
On Tue, Nov 19, 2013 at 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 ind
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 discu
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.
>
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
co
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 qui
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 yo
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 restarted/c
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 d
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, 24x
On 11/17/2013 01:42 AM, Tom Lane wrote:
> Hannu Krosing 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 x()
...
>>> x()
Hannu Krosing 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.
regards,
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
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/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
‘
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’ [-Wimplicit-function-dec
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 f
29 matches
Mail list logo
