Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integerout of range" - Mailing list pgsql-general

From Gavin Flower
Subject Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integerout of range"
Date
Msg-id deaffe76-0492-1e36-f507-57ad37abb4ec@archidevsys.co.nz
Whole thread Raw
In response to Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integerout of range"  (John McKown <john.archie.mckown@gmail.com>)
Responses Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes"integer out of range"  (Gavan Schneider <pg-gts@snkmail.com>)
List 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 by date:

Previous
From: John McKown
Date:
Subject: Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integerout of range"
Next
From: Tom Ekberg
Date:
Subject: [GENERAL] could not translate host name