Re: Off-by-one oddity in minval for decreasing sequences

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Off-by-one oddity in minval for decreasing sequences
Date: 2017-01-13 22:59:39
Message-ID: CAB7nPqQM3tc3AnWh=ZeNB-j3NSj=dEvtFpFgG70BPemB2CO-oQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 7, 2017 at 4:15 AM, Daniel Verite <daniel(at)manitou-mail(dot)org> wrote:
> The defaults comes from these definitions, in include/pg_config_manual.h
>
> /*
> * Set the upper and lower bounds of sequence values.
> */
> #define SEQ_MAXVALUE PG_INT64_MAX
> #define SEQ_MINVALUE (-SEQ_MAXVALUE)
>
> with no comment as to why SEQ_MINVALUE is not PG_INT64_MIN.

Bruce likely does not remember 8000fdd4 from 2003. I stopped tracking there.

> When using other types than bigint, Peter's patch fixes the inconsistency
> but also makes it worse by ISTM applying the rule that the lowest value
> is forbidden for int2 and int4 in addition to int8.

I think that mapping a sequence to a data type gives a good argument
to have the range mapping with the data type involved. That's less
surprise for the users, and less code to think about range boundaries.
Also, restoring from a dump sequences won't result in an error for
sequence definitions using PG_INT**_MIN as minimum value.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-01-13 23:06:31 Re: Protect syscache from bloating with negative cache entries
Previous Message Tom Lane 2017-01-13 22:58:41 Re: Protect syscache from bloating with negative cache entries