X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 4A2E65E46D3 for ; Tue, 17 Aug 2004 14:23:35 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 74276-06 for ; Tue, 17 Aug 2004 17:23:31 +0000 (GMT) Received: from wolff.to (wolff.to [66.93.249.74]) by svr1.postgresql.org (Postfix) with SMTP id 758B75E37CE for ; Tue, 17 Aug 2004 14:23:29 -0300 (ADT) Received: (qmail 25438 invoked by uid 500); 17 Aug 2004 17:31:50 -0000 Date: Tue, 17 Aug 2004 12:31:50 -0500 From: Bruno Wolff III To: Markus Bertheau Cc: Jean-Luc Lachance , pgsql-sql@postgresql.org Subject: Re: SELECT MAX(c) FROM (SELECT ... FOR UPDATE) AS foo Message-ID: <20040817173150.GA22036@wolff.to> Mail-Followup-To: Markus Bertheau , Jean-Luc Lachance , pgsql-sql@postgresql.org References: <1092740863.2627.17.camel@dicaprio.akademie1.de> <41221580.7070907@sympatico.ca> <1092754281.2627.28.camel@dicaprio.akademie1.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1092754281.2627.28.camel@dicaprio.akademie1.de> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200408/177 X-Sequence-Number: 18674 On Tue, Aug 17, 2004 at 16:51:21 +0200, Markus Bertheau wrote: > ?? ??????, 17.08.2004, ?? 16:26, Jean-Luc Lachance ??????????: > > This query does not make sense to me. > > Why would you create an updatable subquery just to get the highest value? > > To make sure that the highest value will be the highest value (or then > second-highest) after I commit the transaction. See my other answer. If you just need ordering that isn't too sensitive to overlapping transactions, then using a sequence (using a serial type is a convenient way to do this) is probably your best bet. You need to make sure the value won't roll over. But at worst a bigserial should be needed to do this. There will potentially be gaps in the numbers allocated accross the table. There will be gaps in the numbers allocated for any value of name. However, if all you need is ordering that shouldn't matter.