Re: Column information

From: Igor Korot <ikorot01(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alban Hertroys <haramrae(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Column information
Date: 2017-05-04 15:53:05
Message-ID: CA+FnnTw8tGwNiEKc3UB67P_5qPPHawQ2oWX+Uqyx0G=_T6R1jg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

David et al,

On Thu, May 4, 2017 at 11:27 AM, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Thu, May 4, 2017 at 8:08 AM, Igor Korot <ikorot01(at)gmail(dot)com> wrote:
>>
>> Hi, guys,
>>
>> On Thu, May 4, 2017 at 10:54 AM, Adrian Klaver
>> <adrian(dot)klaver(at)aklaver(dot)com> wrote:
>> > 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.
>>
>> So basically what you are all saying is that since the value "32"
>> contains 2 digits:
>> "3" and "2" the column radix will contain "2". And it is not the
>> actual representation
>> of the number 32 the radix applies to.
>>
>> Am I right?
>>
>
> No.
>
> 32 is the number of digits/positions available to represent a number.
>
> 2 is the base of the number being represented.
>
> Therefore there are 2 ^ 32 possible numbers that can be represented by this
> column.
>
> If the radix was instead 10, and the precision was still 32 - which is
> acceptable - there would instead be 10 ^ 32 possible numbers that could be
> represented.
>
> And yes, we are talking about parts of numbers here but the concept holds.
> Its too early for me to get my head around precision/scale...
>
> So one column is the base and the other is the exponent.

So if I write for example:

CREATE TABLE foo(id INTEGER PRIMARY KEY, label VARCHAR(50), price
DOUBLE(10, 2));

how can I get 50, 10 and 2 from those 5 fields?

I thought that this is what will be stored in the columns table...

Thank you.

>
> David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2017-05-04 16:01:17 Re: Column information
Previous Message Tom Lane 2017-05-04 15:49:28 Re: Column information