X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id EB663D1F78C for ; Sun, 9 May 2004 02:33:19 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 96294-10 for ; Sun, 9 May 2004 02:32:58 -0300 (ADT) Received: from vscan01.westnet.com.au (vscan01.westnet.com.au [203.10.1.131]) by svr1.postgresql.org (Postfix) with ESMTP id 607F1D1F018 for ; Sun, 9 May 2004 02:32:57 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 79E0B51E06; Sun, 9 May 2004 13:32:56 +0800 (WST) Received: from [192.168.1.9] (dsl-202-72-133-22.wa.westnet.com.au [202.72.133.22]) by vscan01.westnet.com.au (Postfix) with ESMTP id EA18051DBF; Sun, 9 May 2004 13:32:55 +0800 (WST) Message-ID: <409DC28A.7010509@familyhealth.com.au> Date: Sun, 09 May 2004 13:32:58 +0800 From: Christopher Kings-Lynne User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alvaro Herrera Cc: Bruce Momjian , elein , PostgreSQL-development Subject: Re: Adding MERGE to the TODO list (resend with subject) References: <200405082246.i48MkTQ29755@candle.pha.pa.us> <409D8E48.3070805@familyhealth.com.au> <20040509035405.GA917@dcc.uchile.cl> <409DAFEB.7020300@familyhealth.com.au> <20040509051825.GB917@dcc.uchile.cl> In-Reply-To: <20040509051825.GB917@dcc.uchile.cl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200405/444 X-Sequence-Number: 53522 >>Except you can keep trying and trying without the outermost transaction >>failing. > > But that won't provide the necessary next key locking you mentioned in > your first email, will it? No, but since I can loop an infinite number of times until either the update or insert works, I don't need next key locking. BTW, the reference in MySQL: http://dev.mysql.com/doc/mysql/en/REPLACE.html Hmm...no refernce to next key locking. Maybe that's an Innodb thing... Anyway, you can see how they've implemented their algorithm. Here is docs on the DB2 merge command from which the standard was derived: http://databasejournal.com/features/db2/article.php/10896_3322041_2 Chris