Re: [HACKERS] Off-by-one oddity in minval for decreasing sequences - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Off-by-one oddity in minval for decreasing sequences
Date
Msg-id CAB7nPqQM3tc3AnWh=ZeNB-j3NSj=dEvtFpFgG70BPemB2CO-oQ@mail.gmail.com
Whole thread Raw
List pgsql-hackers
On Sat, Jan 7, 2017 at 4:15 AM, Daniel Verite <daniel@manitou-mail.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Protect syscache from bloating with negative cache entries
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Protect syscache from bloating with negative cacheentries