From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: triggers on prepare, commit, rollback... ? |
Date: | 2008-05-20 10:37:35 |
Message-ID: | 20080520103735.GG27988@frubble.xen.chris-lamb.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 20, 2008 at 06:38:17AM +0100, James Mansion wrote:
> Tom Lane wrote:
> >Another response I've heard is "but I don't want to make
> >inside-the-database changes, I want to propagate the state to someplace
> >external". Of course that's completely broken too, because there is
>
> Some
> things are idempotent and are effectively hints - that they are not
> transacted can be well understood and accomodated.
The "idempotent" comment makes sense, hints I'm not so sure about as
they sound as though they've got very complicated semantics.
One operation that fits the transaction BEGIN/END (either COMMIT or
ROLLBACK) semantics well, that I can think of is that of the now()
function. It can be modelled in at least a couple of ways using
transaction begin/end. If you have a BEGIN trigger, then when a
transaction is run it would save the time in a transaction level
variable. If you have an END trigger, then this variable would be
reset, the now() function would need to check on every call to see if
it's missing and set it to the current time if it's missing, otherwise
it should return its value.
Could this be modelled without using transaction level triggers?
Sam
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2008-05-20 11:09:26 | Re: triggers on prepare, commit, rollback... ? |
Previous Message | Nikhils | 2008-05-20 10:32:20 | plpgsql: penalty due to double evaluation of parameters |