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

Re: REPLACE INTO table a la mySQL

From: mlw <markw(at)mohawksoft(dot)com>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: REPLACE INTO table a la mySQL
Date: 2001-06-06 02:26:44
Message-ID: 3B1D94E4.2D8FA297@mohawksoft.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Christopher Kings-Lynne 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.
> >
> > I don't know if it is standard SQL, but it will save hundreds of
> > lines of code
> > in applications everywhere. I LOVE the idea. I just finished
> > writing a database
> > merge/update program which could have been made much easier to
> > write with this
> > syntax.
> 
> The reason MySQL probably has it though is because it doesn't support proper
> transactions.
> 
> While we're at it, why not support the MySQL alternate INSERT syntax
> (rehetorical):
> 
> INSERT INTO table SET field1='value1', field2='value2';

That is not an issue, but a "REPLACE" syntax can take the place of this:

SQL("select * from table where ID = fubar");

if(HAS_VALUES(SQL))
	SQL("update table set xx=yy, www=zz where ID = fubar");
else
	SQL("insert into table (...) values (...)");


REPLACE into table set xx=yy, ww = zz where ID = fubar;

A MUCH better solution!

In response to

Responses

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2001-06-06 04:42:41
Subject: RE: place for newbie postgresql hackers to work
Previous:From: Christopher Kings-LynneDate: 2001-06-06 02:10:44
Subject: RE: Re: REPLACE INTO table a la mySQL

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