Re: Generating Lots of PKs with nextval(): A Feature Proposal

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

In response to

Browse pgsql-hackers by date

  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