Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integerout of range"
От | Gavin Flower |
---|---|
Тема | Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integerout of range" |
Дата | |
Msg-id | deaffe76-0492-1e36-f507-57ad37abb4ec@archidevsys.co.nz обсуждение исходный текст |
Ответ на | Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integerout of range" (John McKown <john.archie.mckown@gmail.com>) |
Ответы |
Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes"integer out of range"
|
Список | pgsql-general |
On 25/02/17 08:39, John McKown wrote: > On Fri, Feb 24, 2017 at 1:25 PM, David G. Johnston > <david.g.johnston@gmail.com <mailto:david.g.johnston@gmail.com>>wrote: > > On Friday, February 24, 2017, Tom Lane <tgl@sss.pgh.pa.us > <mailto:tgl@sss.pgh.pa.us>> wrote: > > Justin Pryzby <pryzby@telsasoft.com> writes: > > Is this expected behavior ? > > ts=# SELECT x'00000000F'::int; > > ERROR: 22003: integer out of range > > LOCATION: bittoint4, varbit.c:1575 > > Yes. The provided operation is "convert a bitstring of up to > 32 bits > to an integer". It's not "guess whether it's okay to throw > away some > bits to make an integer". > > > IME The error message itself is to blame here - we are checking > for a malformed (too many characters) integer > varbit representation but then reporting that the we somehow got a > valid integer but that it is "out of range". > > > A better reply would be good. Another possibility is for the parser > to remove unneeded leading zeros. > [...] I think the latter would be a good idea! Cheers, Gavin
В списке pgsql-general по дате отправления: