Re: "Triggered data change violation", once again

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: "Triggered data change violation", once again
Date: 2001-10-25 00:39:10
Message-ID: Pine.BSF.4.21.0110241733120.58431-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 what the spec
> actually says is thou shalt not change it more than once per
> *statement*. We have discussed this several times in the past and
> I think people have agreed that the current behavior is wrong,
> but nothing's been done about it.
>
> 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 things that might update the command ID during the execution
of the statement from inside functions that are being run? I really don't
understand the details of how that works (which is the biggest reason I
haven't yet tackled some of the big remaining broken stuff in the
referential actions, because AFAICT we need to be able to update a row
that matched at the beginning of the statement, not the ones that match
at the time the triggers run).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-10-25 00:49:14 Re: "Triggered data change violation", once again
Previous Message Tom Lane 2001-10-25 00:37:45 Re: Proposed new create command, CREATE OPERATOR CLASS