Re: MERGE vs REPLACE - Mailing list pgsql-hackers

From Jaime Casanova
Subject Re: MERGE vs REPLACE
Date
Msg-id c2d9e70e0511151124o31d86e21n7d60c46dea2a1ce6@mail.gmail.com
Whole thread Raw
In response to Re: MERGE vs REPLACE  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On 11/15/05, Josh Berkus <josh@agliodbs.com> wrote:
> Simon,
>
> > The UPSERT concept is also supported by Teradata, who simply append an
> > ELSE INSERT clause onto the standard UPDATE syntax. MySQL REPLACE seems
> > to me to be a fairly small subset of MERGE functionality and we ought to
> > be able to offer that functionality as a side branch of the main work.
>
> Yes, I guess my hesitation on the full-table-lock strategy is that it
> doesn't really fulfill the mandate for why people want REPLACE-like
> statements ... to give them an INSERT-or-UPDATE with *higher* efficiency
> and concurrency than doing two statements.  That being said, I've
> personally designed more than a dozen web applications and have not yet
> been faced with a single circumstance of not knowing whether I wanted to
> INSERT or UPDATE.  I've even ported MySQL apps and found it easy to
> re-code them to do "if $id = 0, then insert ..." without even needing to
> use a pl/pgsql hack.
>

Actually REPLACE is not INSERT or UPDATE...
REPLACE means INSERT if already exists DELETE then INSERT

can be used as an UPDATE if you use the SET clause but, it is optional


--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator ;)


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: MERGE vs REPLACE
Next
From: "Magnus Hagander"
Date:
Subject: Re: R?f. : RE: Running PostGre on DVD