Re: mysql replace in postgreSQL?

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
Cc: David Fetter <david(at)fetter(dot)org>, blackwater dev <blackwaterdev(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: mysql replace in postgreSQL?
Date: 2005-11-02 05:28:17
Message-ID: 43684E71.80604@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 10/31/2005 11:58 AM, Lincoln Yeoh wrote:

> At 08:24 AM 10/30/2005 -0800, David Fetter wrote:
>
>> > >http://developer.postgresql.org/docs/postgres/plpgsql-control-structure
>> s.html#PLPGSQL-ERROR-TRAPPING
>> >
>> > Erm, doesn't it have the same race conditions?
>>
>>No, don't believe it does. Have you found some?
>
> Depends on how you do things.
>
> As I mentioned, it's only fine if you have the relevant uniqueness constraint.

One would use MySQL's REPLACE INTO to avoid duplicates. To deliberately
omit the UNIQUE constraint in order to make the stored procedure
solution fail would smell a lot like the old MySQL crashme BS ... first
create and drop 10,000 tables to bloat the system catalog, next vacuum
with a user that doesn't have privileges to vacuum system catalogs
(because we told them to vacuum after that silly crap test), then show
that the system is still slow.

Using REPLACE INTO at one place and creating duplicates on purpose in
another seems to make zero sense to me. Until one can explain the reason
for that to me, I claim that a UNIQUE constraint on such key is a
logical consequence.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Guido Neitzer 2005-11-02 06:27:49 Re: PostgreSQL, Mac OS X and locales
Previous Message Venki 2005-11-02 04:47:49 Re: Disappearing Records