Re: INSERT ON DUPLICATE KEY UPDATE - Mailing list pgsql-general

From Robert Treat
Subject Re: INSERT ON DUPLICATE KEY UPDATE
Date
Msg-id 1087589711.2111.51.camel@camel
Whole thread Raw
In response to Re: INSERT ON DUPLICATE KEY UPDATE  (Duane Lee - EGOVX <DLee@mail.maricopa.gov>)
Responses Re: INSERT ON DUPLICATE KEY UPDATE
Re: INSERT ON DUPLICATE KEY UPDATE
List pgsql-general
IIRC the standard syntax is based on db2's horrendous merge on command,
which was only added to the standard a couple months back.

IIRC the main downside to the select/update method is it introduces a
race condition that can only be solved by locking the table; not an
issue for most my$ql apps but would be frowned upon by most postgresql
users.

Robert Treat

On Fri, 2004-06-18 at 15:00, Duane Lee - EGOVX wrote:
> I agree.  You could always do a SELECT and if the record was found then
> UPDATE otherwise INSERT.  A little more effort than MYSQL but again I
> don't believe the way MYSQL is allowing you to do it is standard.
>
> Duane
>
> -----Original Message-----
> From: Richard Huxton [ mailto:dev@archonet.com <mailto:dev@archonet.com>
> ]
> Sent: Friday, June 18, 2004 11:02 AM
> To: Eduardo Pérez Ureta
> Cc: Duane Lee - EGOVX; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] INSERT ON DUPLICATE KEY UPDATE
>
>
> Eduardo Pérez Ureta wrote:
> > On 2004-06-18 17:19:40 UTC, Duane Lee - EGOVX wrote:
> >
> >>I would suspect you would need to write a trigger to do this.
> >
> >
> > It seems the mysql way of doing this is easier and safer.
>
> And non-standard AFAIK.
>
> > Why is that not implemented in postgresql?
> > Is it better done with a trigger or with any other way?
>
> Out of curiosity, why don't you know whether you're inserting or
> updating? It always worries me when I don't know what my application is
> doing.
>
> --
>    Richard Huxton
>    Archonet Ltd
>

--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


pgsql-general by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: can't win
Next
From: Dennis Gearon
Date:
Subject: UTF8 vs C_LOCALE