Re: [GENERAL] Column information - Mailing list pgsql-general

David et al,

On Thu, May 4, 2017 at 11:27 AM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Thu, May 4, 2017 at 8:08 AM, Igor Korot <ikorot01@gmail.com> wrote:
>>
>> Hi, guys,
>>
>> On Thu, May 4, 2017 at 10:54 AM, Adrian Klaver
>> <adrian.klaver@aklaver.com> wrote:
>> > On 05/04/2017 07:44 AM, Tom Lane wrote:
>> >>
>> >> Adrian Klaver <adrian.klaver@aklaver.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.