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
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 |