Tom Lane wrote:
>
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> I think all we need to do to implement things correctly is to consider a
> >> previous event only if both xmin and cmin of the old tuple match the
> >> current xact & command IDs, rather than considering it on the basis of
> >> xmi
On Wed, 24 Oct 2001, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> I think all we need to do to implement things correctly is to consider a
> >> previous event only if both xmin and cmin of the old tuple match the
> >> current xact & command IDs, rather than considering it on
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> I think all we need to do to implement things correctly is to consider a
>> previous event only if both xmin and cmin of the old tuple match the
>> current xact & command IDs, rather than considering it on the basis of
>> xmin alone.
> Are there any th
On Wed, 24 Oct 2001, Tom Lane wrote:
> The only reason we do this is to enforce the "triggered data change
> violation" restriction of the spec. However, I think we've
> misinterpreted the spec. The code prevents an RI referenced value from
> being changed more than once in a transaction, but w
Tom Lane writes:
> Cedar Cox <[EMAIL PROTECTED]> writes:
> > Added note: The trigger is a BEFORE trigger.
>
> AFAIK the "triggered data change" message comes out of the AFTER trigger
> code. You sure you don't have any AFTER triggers on the table? Perhaps
> ones added implicitly by a foreign-k
Cedar Cox <[EMAIL PROTECTED]> writes:
> Added note: The trigger is a BEFORE trigger.
AFAIK the "triggered data change" message comes out of the AFTER trigger
code. You sure you don't have any AFTER triggers on the table? Perhaps
ones added implicitly by a foreign-key constraint?
On Tue, 20 Mar 2001, Tom Lane wrote:
> Cedar Cox <[EMAIL PROTECTED]> writes:
> > Added note: The trigger is a BEFORE trigger.
>
> AFAIK the "triggered data change" message comes out of the AFTER trigger
> code. You sure you don't have any AFTER triggers on the table? Perhaps
> ones added impl
Cedar Cox <[EMAIL PROTECTED]> writes:
>> AFAIK the "triggered data change" message comes out of the AFTER trigger
>> code. You sure you don't have any AFTER triggers on the table? Perhaps
>> ones added implicitly by a foreign-key constraint?
> Not any that I wrote. Ok, the table def is:
> CRE
> A "triggered data change violation" happens everytime you change twice
> within a transaction a value (column) that is part of a foreign key
> constraint (don't recall exactly which part).
>
> This error shouldn't really happen, but I recall there were some
> implementation and definition probl
