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).
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 |