Re: REPLACE INTO table a la mySQL

From: mlw <markw(at)mohawksoft(dot)com>
To: Dale Johnson <djohnson(at)mi(dot)ab(dot)ca>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: REPLACE INTO table a la mySQL
Date: 2001-06-11 15:52:28
Message-ID: 3B24E93C.7EA0496B@mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dale Johnson wrote:

> "Jan Wieck" <JanWieck(at)Yahoo(dot)com> wrote in message
> news:200106061506(dot)f56F6dV01843(at)jupiter(dot)us(dot)greatbridge(dot)com(dot)(dot)(dot)
> > mlw wrote:
> > > [...]
> > > REPLACE into table set xx=yy, ww = zz where ID = fubar;
> > >
> > > A MUCH better solution!
> >
> > Please solve the trigger problem at least theoretical before
> > claiming that mySQL is that MUCH better. And please don't
> > solve it by ripping out trigger support :-)
> >
> for INSERT OR REPLACE into table ...
> if the record was not there, fire the insert trigger
> else
> delete the row (fire delete trigger)
> insert the new row (fire the insert trigger)
> fi
>
> semantically no other way, I think

I'm not sure I agree. There are explicit triggers for update, insert, and
delete, therefor why not also have a trigger for replace? It is one more
case. Rather than try to figure out how to map replace into two distinct
behaviors of insert or update based on some conditional logic, why not just
have a replace trigger?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-06-11 16:03:54 Re: inet/cidr type comparisons
Previous Message Peter Eisentraut 2001-06-11 14:56:36 Re: dlopen() of libpgsqlodbc.so >= release 7.1 fails on sparc solaris 2.8