From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Igor Korot <ikorot01(at)gmail(dot)com>, Alban Hertroys <haramrae(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Column information |
Date: | 2017-05-04 14:54:09 |
Message-ID: | 6b8f7439-4872-37d4-0d2b-e9f05ee4041d@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 05/04/2017 07:44 AM, Tom Lane wrote:
> Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:
>> Alright I see that, but why does my example show a
>> numeric_precision_radix of 10?
>
>> Is there some transition point where it goes from base 10 to base 2?
>
> In PG, "numeric" always has radix 10, because the underlying
> implementation is decimal, and all other numerical types such as int and
> float have radix 2, because the underlying implementation is binary.
> Other DBMSses could perhaps do it differently.
>
> Hmm ... you could argue that numeric_precision_radix is telling you
> something about the type's arithmetic behavior independently of what
> the particular column's maximum-precision-if-any is. That's not how
> the SQL spec defines it, but that's really what it's doing.
>
>> Also why does the OPs query show anything when the data_type is integer?
>
> The point is that our integers are 32-bit integers, not some other size.
> If you try it on bigint or smallint columns, you'll get other answers.
Got it thanks, I was being too literal in my interpretation of numeric.
>
> regards, tom lane
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Igor Korot | 2017-05-04 15:08:15 | Re: Column information |
Previous Message | Adrian Klaver | 2017-05-04 14:49:34 | Re: Column information |