From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Philippe Ferreira <phil(dot)f(at)worldonline(dot)fr> |
Cc: | jim(at)contactbda(dot)com, pgsql-general(at)postgresql(dot)org |
Subject: | Re: My very first PL/pgSQL procedure... |
Date: | 2006-01-28 15:16:08 |
Message-ID: | 20060128151608.GB16773@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Jan 26, 2006 at 09:04:25PM +0100, Philippe Ferreira wrote:
> But because the sequence could not be locked, some concurrent
> transactions could have already raised it's current value in the
> meantime to, say, "1002", before the effective execution of setval().
Umm, locking sequences won't ever happen. The *whole point* of
sequences is that you get a unique number and you don't have to wait
for it. By locking you'd be telling other people they have to wait.
> So, instead of raising the value to 1000, my function could have
> done the opposite (from 1002 to 1000) ! And the two next "INSERT"
> using this sequence would then break !!
I think you need to provide a rationale why you want to control the
value of the sequence in such a way anyway, because you're trying to do
something that the system isn't likely to support. The numbers are
supposed to be "opaque", the actual values are not supposed to be
relevent.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-28 15:18:15 | Re: stats for failed transactions (was Re: [GENERAL] VACUUM Question) |
Previous Message | Martijn van Oosterhout | 2006-01-28 14:38:54 | Re: Encoding errors when upgrading from 7.4 to 8.1 |