Skip site navigation (1) Skip section navigation (2)

Re: REPLACE INTO table a la mySQL

From: mlw <markw(at)mohawksoft(dot)com>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Dale Johnson <djohnson(at)mi(dot)ab(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: REPLACE INTO table a la mySQL
Date: 2001-06-06 20:57:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jan Wieck wrote:

> Dale Johnson wrote:
> > I know we're not in the business of copying mySQL,
> > but the REPLACE INTO table (...) values (...) could be
> > a useful semantic.  This is a combination INSERT or
> > UPDATE statement.  For one thing, it is atomic, and
> > easier to work with at the application level.  Also
> > if the application doesn't care about previous values,
> > then execution has fewer locking issues and race
> > conditions.
> >
> > comments?
>     First  it's  not  standard  SQL, so chances aren't that good.
>     Second, how do you think the  system  should  behave  in  the
>     following case:
>     * Table  A  has  one  trigger BEFORE INSERT doing some checks
>       plus inserting a row into table newA and updating a row  in
>       table  balanceA.   It  also  has triggers BEFORE UPDATE and
>       BEFORE DELETE that update balanceA.
>     * Now we do your REPLACE INTO
>     The problem is that in a concurrent multiuser environment you
>     cannot  know  if  that  row  exists until you actually do the
>     insert (except you lock the  entire  table  and  check  for).
>     Since  there's  a  BEFORE  trigger  which  potentially  could
>     suppress the INSERT, you can't do the insert  before  fireing
>     it. Now it has been run, did it's inserts and updates and the
>     statement must be converted into an UPDATE  because  the  row
>     exists - how do you undo the trigger work?
>     I  know,  mySQL  doesn't have triggers, referential integrity
>     and all that damned complicated stuff. That's why it can have
>     such a powerful non-standard command like REPLACE INTO.
> Jan

Perhaps it is as easy as saying that this feature is a non-standard
extension to SQL, thus a non-standard trigger mechanism is used.

The trigger will be on the statement replace. The trigger function will
carry with it the tuple, and the previous one if one exists.

create trigger my_trigger before update or insert or delete or replace

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-06-06 21:25:21
Subject: Re: And what about that Debugfile?
Previous:From: Thomas LockhartDate: 2001-06-06 20:55:42
Subject: Re: Timestamp change - 8601 compliance

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group