Skip site navigation (1) Skip section navigation (2)

Re: SELECT MAX(c) FROM (SELECT ... FOR UPDATE) AS foo

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Markus Bertheau <twanger(at)bluetwanger(dot)de>
Cc: Jean-Luc Lachance <jllachan(at)sympatico(dot)ca>,pgsql-sql(at)postgresql(dot)org
Subject: Re: SELECT MAX(c) FROM (SELECT ... FOR UPDATE) AS foo
Date: 2004-08-17 17:31:50
Message-ID: 20040817173150.GA22036@wolff.to (view raw or flat)
Thread:
Lists: pgsql-sql
On Tue, Aug 17, 2004 at 16:51:21 +0200,
  Markus Bertheau <twanger(at)bluetwanger(dot)de> 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.

In response to

pgsql-sql by date

Next:From: Josh BerkusDate: 2004-08-18 02:45:15
Subject: Re: multi column foreign key for implicitly unique columns
Previous:From: Adam LancasterDate: 2004-08-17 17:21:22
Subject: Possible rounding error of large float values?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group