without unique constraint even mysql replace doesnot work as expected
Jan Wieck wrote:
> 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
>
