David et al, On Thu, May 4, 2017 at 11:27 AM, David G. Johnston <david.g.johnston@xxxxxxxxx> wrote: > On Thu, May 4, 2017 at 8:08 AM, Igor Korot <ikorot01@xxxxxxxxx> wrote: >> >> Hi, guys, >> >> On Thu, May 4, 2017 at 10:54 AM, Adrian Klaver >> <adrian.klaver@xxxxxxxxxxx> wrote: >> > On 05/04/2017 07:44 AM, Tom Lane wrote: >> >> >> >> Adrian Klaver <adrian.klaver@xxxxxxxxxxx> 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
