Thread: failed Delete after Insert in a transaction

failed Delete after Insert in a transaction

From
"Andrew Snow"
Date:
Why won't PostgreSQL let me do this?

db=# begin;
BEGIN
db=# insert into foo (name) values ('hmmm');
INSERT 22288 1
db=# delete from foo where name='hmmm';
ERROR:  triggered data change violation on relation "foo"
db=# abort;

The table foo is defined like this:

CREATE TABLE foo (
  ID    serial PRIMARY KEY,
  Name  text NOT NULL
  );


I can't work out what I am doing wrong!


Note, there is another table that REFERENCES this table, but as you can see
in the example transaction above, I don't touch any other tables.  Also note
that it works fine outside of a transaction.

I am running postgresql 7.02 on FreeBSD 3.4-STABLE.


Thanks


Andrew




Re: failed Delete after Insert in a transaction

From
"Alex Bolenok"
Date:
> Why won't PostgreSQL let me do this?
>
> db=# begin;
> BEGIN
> db=# insert into foo (name) values ('hmmm');
> INSERT 22288 1
> db=# delete from foo where name='hmmm';
> ERROR:  triggered data change violation on relation "foo"
> db=# abort;
>
> The table foo is defined like this:
>
> CREATE TABLE foo (
>   ID    serial PRIMARY KEY,
>   Name  text NOT NULL
>   );
>
>
> I can't work out what I am doing wrong!
>
>
> Note, there is another table that REFERENCES this table, but as you can
see
> in the example transaction above, I don't touch any other tables.  Also
note
> that it works fine outside of a transaction.
>
> I am running postgresql 7.02 on FreeBSD 3.4-STABLE.
>
>
> Thanks
>
>
> Andrew

You should commit transaction before changing any foreign key that was
affected by this transaction.

So if you really want to delete the row you have just inserted (I wonder why
:) you should write your own FOREIGN KEY triggers. It implies performance
loss, but allows you to do everything you want over the referenced fields.

Alex Bolenok.


Re: failed Delete after Insert in a transaction

From
JanWieck@t-online.de (Jan Wieck)
Date:
Andrew Snow wrote:
>
> Why won't PostgreSQL let me do this?
>
> db=# begin;
> BEGIN
> db=# insert into foo (name) values ('hmmm');
> INSERT 22288 1
> db=# delete from foo where name='hmmm';
> ERROR:  triggered data change violation on relation "foo"
> db=# abort;
>
> The table foo is defined like this:
>
> CREATE TABLE foo (
>   ID    serial PRIMARY KEY,
>   Name  text NOT NULL
>   );
>
>
> I can't work out what I am doing wrong!
>
>
> Note, there is another table that REFERENCES this table, but as you can see
> in the example transaction above, I don't touch any other tables.  Also note
> that it works fine outside of a transaction.

    It is according to the SQL3 specs, that you cannot modify one
    and the same row, that is or might be subject to  referential
    integrity  or triggers, multiple times in one transaction. If
    you touch anything else or not doesn't matter.

>
> I am running postgresql 7.02 on FreeBSD 3.4-STABLE.
>
>
> Thanks
>
>
> Andrew
>
>


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



Re: failed Delete after Insert in a transaction

From
Stephan Szabo
Date:
On Sun, 23 Jul 2000, Jan Wieck wrote:

> Andrew Snow wrote:
> >
> > Why won't PostgreSQL let me do this?
> >
> > db=# begin;
> > BEGIN
> > db=# insert into foo (name) values ('hmmm');
> > INSERT 22288 1
> > db=# delete from foo where name='hmmm';
> > ERROR:  triggered data change violation on relation "foo"
> > db=# abort;
> >
> > The table foo is defined like this:
> >
> > CREATE TABLE foo (
> >   ID    serial PRIMARY KEY,
> >   Name  text NOT NULL
> >   );
> >
> >
> > I can't work out what I am doing wrong!
> >
> >
> > Note, there is another table that REFERENCES this table, but as you can see
> > in the example transaction above, I don't touch any other tables.  Also note
> > that it works fine outside of a transaction.
>
>     It is according to the SQL3 specs, that you cannot modify one
>     and the same row, that is or might be subject to  referential
>     integrity  or triggers, multiple times in one transaction. If
>     you touch anything else or not doesn't matter.

Seems like a fairly silly restriction in this case .  I wonder why they
added it?  Oh well, ours is not to wonder why, right?

Admittedly, the SQL92 triggered data change is also fairly dumb, since
it seems to only be possible with real stupid setups (one column that
is reference to multiple other things that themselves reference each
other) or MATCH PARTIAL.


Re: failed Delete after Insert in a transaction

From
JanWieck@t-online.de (Jan Wieck)
Date:
Stephan Szabo wrote:
> On Sun, 23 Jul 2000, Jan Wieck wrote:
>
> > Andrew Snow wrote:
> > >
> > > Why won't PostgreSQL let me do this?
> > >
> > > db=# begin;
> > > BEGIN
> > > db=# insert into foo (name) values ('hmmm');
> > > INSERT 22288 1
> > > db=# delete from foo where name='hmmm';
> > > ERROR:  triggered data change violation on relation "foo"
> > > db=# abort;
> > >
> > > The table foo is defined like this:
> > >
> > > CREATE TABLE foo (
> > >   ID    serial PRIMARY KEY,
> > >   Name  text NOT NULL
> > >   );
> > >
> > >
> > > I can't work out what I am doing wrong!
> > >
> > >
> > > Note, there is another table that REFERENCES this table, but as you can see
> > > in the example transaction above, I don't touch any other tables.  Also note
> > > that it works fine outside of a transaction.
> >
> >     It is according to the SQL3 specs, that you cannot modify one
> >     and the same row, that is or might be subject to  referential
> >     integrity  or triggers, multiple times in one transaction. If
> >     you touch anything else or not doesn't matter.
>
> Seems like a fairly silly restriction in this case .  I wonder why they
> added it?  Oh well, ours is not to wonder why, right?
>
> Admittedly, the SQL92 triggered data change is also fairly dumb, since
> it seems to only be possible with real stupid setups (one column that
> is reference to multiple other things that themselves reference each
> other) or MATCH PARTIAL.

    I  think  it  has  to  do  with  the  possible implementation
    specific differences that arise from it. Have  an  ON  UPDATE
    SET  NULL  referential action, now you UPDATE a key and later
    UPDATE it again to the old values. What should the constraint
    do? Some implementation could state "the value hasn't changed
    from the atomicity PoV". Another one is right too saying  "it
    has been touched in the Xact".


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #