Prev: recovery consistent != hot standby
Next: Parameter oddness; was HS/SR Assert servercrash
From: Robert Haas on 14 May 2010 18:22
On Fri, May 14, 2010 at 6:11 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Peter Crabtree <peter.crabtree(a)gmail.com> writes:
>> On Fri, May 14, 2010 at 5:29 PM, Robert Haas <robertmhaas(a)gmail.com> wrote:
>>> If we do this, I'm inclined to think that the extra argument to
>>> nextval() should be treated as overriding the base increment rather
>>> than specifying a multiplier for it.  Other than that nitpick, it
>>> sounds like a reasonable thing to allow.
>
>> After giving it some thought, that sounds better. You gain some
>> functionality that way (temporarily overriding the interval) and lose
>> none.
>
> Well, what you lose is the previous assurance that values of nextval()
> were always multiples of the increment.  I could see that breaking
> applications that are using non-unity increments.

Err, right. But those applications presumably will also not be using
this new behavior. There are no versions of PG that have an extra
argument to nextval but still guarantee that the values of nextval()
are multiples of the increment.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2
Prev: recovery consistent != hot standby
Next: Parameter oddness; was HS/SR Assert servercrash