John R Pierce wrote
> On 11/7/2013 10:41 AM, Tom Lane wrote:
>>=20
> evgeniy.skomorokhov@
> writes:
>>> >Automaticaly created sequence takes values =C3=A2=E2=82=AC=E2=80=B9=C3=
=A2=E2=82=AC=E2=80=B9from the range [1;
>>> >9223372036854775807] but max value of field which will be filled from
>>> >sequence - max of type integer (2147483647).
>> If you want a bigint column, use "bigserial". Not everybody wants
>> to take that space penalty, though.
>=20
>=20
> I think he's suggesting that a sequence generated from a regular serial=
=20
> probably shouldn't have that 63 bit max_value
The main advantage of the current behavior is if you hit the limit for an
integer you can alter the column type to bigint without having to mess
around with the associated sequence. If the sequence was upper-bound
limited that same conditions that caused the out-of-range error will just
generate a different kind of error (not sure which one if the sequence is
exhausted).
Its definitely not a "bug" whether you believe the behavior should be
changed or not. A sequence is de-coupled from any particular type. Maybe
if there were short, normal, and big sequences with matching performance
improvements it would matter but having only a single sequence
implementation makes the current behavior/defaults reasonable for normal
usage.
I am curious why this even came up. This seems to be the kind of thing mos=
t
people would be oblivious to.
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-8=
582-field-serial-getted-incorrect-value-from-automaticaly-created-its-seque=
nce-tp5777360p5777396.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
