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@Yahoo.com #
