From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Crabtree <peter(dot)crabtree(at)gmail(dot)com>, depesz(at)depesz(dot)com, Kenneth Marshall <ktm(at)rice(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Generating Lots of PKs with nextval(): A Feature Proposal |
Date: | 2010-05-14 22:22:18 |
Message-ID: | AANLkTinyyQHei5PITuv2fTW8TvPRugCr2AKcEZKT9lfj@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 14, 2010 at 6:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Crabtree <peter(dot)crabtree(at)gmail(dot)com> writes:
>> On Fri, May 14, 2010 at 5:29 PM, Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-05-14 22:34:40 | Re: Parameter oddness; was HS/SR Assert server crash |
Previous Message | Robert Haas | 2010-05-14 22:20:32 | Re: max_standby_delay considered harmful |