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.