From: | Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Steve Singer <steve(at)ssinger(dot)info>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sequence data type |
Date: | 2017-03-30 11:46:24 |
Message-ID: | CAKOSWNkP59QRu79ZqToRCdO590AdQ_F0SP2+TOcaE2sg4OuzWA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/29/17, Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> wrote:
> On 3/29/17, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy
>> <vitaly(dot)burovoy(at)gmail(dot)com> wrote:
>>> I think min_value and max_value should not be set to "1" or "-1" but
>>> to real min/max of the type by default.
>>
>> This is the default behavior for ages, since e8647c45 to be exact. So
>> you would change 20 years of history?
>
> ... is it a wrong way to keep historical minimum as "1" by
> default: it is not a minimum of any of supported type.
I've read the standard about "minvalue", "maxvalue" and "start".
OK, I was wrong. Since "start" should be equal to "minvalue" unless
defined explicitly, the only bug left from my first email here is
resetting "minvalue" back to 1 when data type changes and if the value
matches the bound of the old type (the last case there).
P.S.: the same thing with "maxvalue" when "increment" is negative.
--
Best regards,
Vitaly Burovoy
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-03-30 11:57:00 | Re: Patch: Write Amplification Reduction Method (WARM) |
Previous Message | Ashutosh Bapat | 2017-03-30 11:16:20 | Re: postgres_fdw bug in 9.6 |