Re: [GENERAL] ENUM type size

[Олег Самойлов]

On Sat, 2017-09-02 at 18:06 -0400, Tom Lane wrote:
> Because it's really an OID under the hood.

I see.

> > In any use cases, that I know,
> > ENUM 255 values (1 byte) more then enough.
> Only if you consider each enum type in isolation (and even then, I'd
> dispute your argument that nobody has use for more than 255 values).

May be, but then it must be filled not by programmer in code, but
instead by operator of DB or script or routine. In such case it must be
filled by DML, but not DDL statements, thus it must be a foreign table.

But for what ENUM must be for and when is it better, then foreign
table? When set of values is stable, small and can be predefined by
programmer himself. For instance, very common field for each database
is "sex". What type to use for this? Boolean, because it is 1 byte?
It's ugly, boolean is for boolean arithmetics, not for predefined
values. And will need foreign table and one more "join" to translate
true and false to "male" and "female".  Or special function for this.
Who will have "true sex" and who will be "false"? :) This is looking
like sexism. And what to do if this example will be not "sex" (for
which true and false enough, if without a trans-gender or genetic
mosaicism), but other type that need 3 values? Char(1) and 'm'/'f'?
Looked good and can be used without one more "join", but will take 2
bytes for English, 3 bytes for European language, and even more for
Asian. Foreign table and smallint? 2 bytes and one more "join". Bit
string? Yep, can be only 1 byte, but using a bit string for this is
also very ugly. PostgreSQL don't have a suitable type for such common
problem as defining "sex" in DB or similar problem. But has ENUM that
is in the current implementation is not obvious when it can be better
then a old school foreign table.

> Other ways of doing it would have created problems of their own.

May be complex primary key: one field is oid of type of enum, other is
byte. 

>   But
> you can certainly build your own enum type if you don't like the
> tradeoffs
> the core code made.

Good idea. I'll think about this.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] ENUM type size

[Tom Lane]

=?UTF-8?Q?=D0=9E=D0=BB=D0=B5=D0=B3_?= 
=?UTF-8?Q?=D0=A1=D0=B0=D0=BC=D0=BE=D0=B9=D0=BB=D0=BE=D0=B2?=  
writes:
> May I ask the question here or I must go to the pgsql-hackers?
> Why does ENUM type have 4 byte size?

Because it's really an OID under the hood.

> In any use cases, that I know,
> ENUM 255 values (1 byte) more then enough.

Only if you consider each enum type in isolation (and even then, I'd
dispute your argument that nobody has use for more than 255 values).
In our implementation, enum types are essentially all foreign keys into
the same pg_enum catalog, so you definitely need more space.

Other ways of doing it would have created problems of their own.  But
you can certainly build your own enum type if you don't like the tradeoffs
the core code made.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Numeric numbers

[Олег Самойлов]

Thanks for the answer, Tom. Now it's become clear.

On Sat, 2017-09-02 at 16:20 -0400, Tom Lane wrote:
> The information you're missing here is that a numeric value carries a
> "display scale" value which indicates how many fractional digits to
> print.
> So "0.0" (scale 1) and "0." (scale 20) print
> differently, but they occupy the same amount of storage because the
> trailing zeroes are stripped for storage.
> 
> Likewise, the documentation you started with was talking about the
> physical limits of the storage format, not about the actual behavior
> of any particular numeric operation.

You are right. I am rereading the official documentation of PostgreSQL
(9.6) to refresh it in memory. But didn't see any description about
"display scale", only about "scale", which is part of type definition.
I just checked it by google.

https://www.google.ru/search?q=site%3Ahttps%3A%2F%2Fwww.postgresql.org%
2Fdocs%2F9.6%2Fstatic%2F+%22display+scale%22=site%3Ahttps%3A%2F%2Fww
w.postgresql.org%2Fdocs%2F9.6%2Fstatic%2F+%22display+scale%22=chrom
e..69i57j69i58.15543j0j8=chrome=UTF-8

"Display scale" exist only inside release notes. What is interesting,
there is even function scale(numeric) that shows parameter "display
scale" (according to release notes), but according to description in
documentation "scale of the argument (the number of decimal digits in
the fractional part)". May be this definitions are the same, but this
was not obvious. :) I checked:

=> select 1::numeric/3-0.;
?column?

 0.

=> select scale(1::numeric/3-0.);
 scale 
---
20


> As far as the 1/3 example goes, the division has to stop somewhere;
> we can't store an infinite number of digits.  We could carry out the
> division to the physical limit of what numeric could store, but
> nobody
> would like that behavior.  

Yep, it's reasonable, that's why I checked this example. But it is not
documented in description of numeric type and in chapter "Mathematical
Functions and Operators".


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] ENUM type size

[Олег Самойлов]

May I ask the question here or I must go to the pgsql-hackers?

Why does ENUM type have 4 byte size? In any use cases, that I know,
ENUM 255 values (1 byte) more then enough. And it's only reason for
ENUM, if you need more values then 255 you can create a foreign table
with smallint (or bigger) primary key. And, obviously that table will
be filled by operators or routines, not by a programmer. The only
reason for ENUM is to use for fields with very small set of values, for
instance: sex, day of week, month, etc. And 1 byte size is 4 times
shorter then 4 bytes, especially for big tables.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Numeric numbers

[Tom Lane]

=?UTF-8?Q?=D0=9E=D0=BB=D0=B5=D0=B3_?= 
=?UTF-8?Q?=D0=A1=D0=B0=D0=BC=D0=BE=D0=B9=D0=BB=D0=BE=D0=B2?=  
writes:
> What did you mean? 0. is not 0 indeed, but wrongly
> show as 0. Or it's 0, but badly formated as 0.?

Really?

regression=# select 0.;
?column?

 0.
(1 row)

However, it's true that those trailing zeroes aren't physically stored:

regression=# select pg_column_size(0.00::numeric);
 pg_column_size 

  6
(1 row)

regression=# select pg_column_size(0.::numeric);
 pg_column_size 

  6
(1 row)

The information you're missing here is that a numeric value carries a
"display scale" value which indicates how many fractional digits to print.
So "0.0" (scale 1) and "0." (scale 20) print
differently, but they occupy the same amount of storage because the
trailing zeroes are stripped for storage.

Likewise, the documentation you started with was talking about the
physical limits of the storage format, not about the actual behavior
of any particular numeric operation.

As far as the 1/3 example goes, the division has to stop somewhere;
we can't store an infinite number of digits.  We could carry out the
division to the physical limit of what numeric could store, but nobody
would like that behavior.  The current behavior, cf select_div_scale(),
is

 * The result scale of a division isn't specified in any SQL standard. For
 * PostgreSQL we select a result scale that will give at least
 * NUMERIC_MIN_SIG_DIGITS significant digits, so that numeric gives a
 * result no less accurate than float8; but use a scale not less than
 * either input's display scale.

So in this example you get 20 digits by default:

regression=# select 1::numeric / 3;
?column?

 0.
(1 row)

but you can get more by specifying a larger scale for either input:

regression=# select 1::numeric(50,40) / 3;
  ?column?  

 0.
(1 row)

There aren't any hidden digits beyond what you can see; the result
is what it is.  Claiming that there are an infinite number of zeroes
after it seems rather beside the point.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Numeric numbers

[Олег Самойлов]

On Sat, 2017-09-02 at 11:41 -0700, David G. Johnston wrote:
> > There is only 20 "3" after ".". Well, may be this is not a problem,
> > but
> > why are they infinite number of "0" after the point? I can write
> > even
> > 
> > => select (1::numeric/3-0.)*1e10;
> > ?column?        
> > 
> >  0.
> > 
> > Result the same. According to the docs: "Numeric values are
> > physically
> > stored without any extra leading or trailing zeroes."
> > 
> > 
> What you see on the screen is not what is physically stored.  The
> documentation about the numeric type on the server is accurate, but
> apparently the psql application takes some liberties as to what it
> chooses to display.   It's display rules for numeric don't seem to be
> user documented or configurable.
> 
> David J,

What did you mean? 0. is not 0 indeed, but wrongly
show as 0. Or it's 0, but badly formated as 0.?


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Numeric numbers

[David G. Johnston]

On Saturday, September 2, 2017, Олег Самойлов  wrote:
>
> There is only 20 "3" after ".". Well, may be this is not a problem, but
> why are they infinite number of "0" after the point? I can write even
>
> => select (1::numeric/3-0.)*1e10;
> ?column?
> 
>  0.
>
> Result the same. According to the docs: "Numeric values are physically
> stored without any extra leading or trailing zeroes."
>
>
What you see on the screen is not what is physically stored.  The
documentation about the numeric type on the server is accurate, but
apparently the psql application takes some liberties as to what it chooses
to display.   It's display rules for numeric don't seem to be user
documented or configurable.

David J,

Re: [GENERAL] Numeric numbers

[Francisco Olarte]

Олег:

On Sat, Sep 2, 2017 at 7:04 PM, Олег Самойлов  wrote:
...

>> Well, I just skipped over the rest of the code. I consider casting to
>> unespecified numeric widths a very bad habit and did not want to
>> encourage it.
> There is nothing in documentation that this casting is a very bad
> habit. And this is most interesting part, about infinite zeros. Looked
> like a bug.

It's not in the documentation, as it rarely deals with habits and
styles. And many people could consider it perfectly kosher. It's just
something  *I* consider a bad habit personally, feel free to use it as
much as you like, or to recomend it as good if you want. Normally I
wouldn't even mention it, as I did not in my first response, I just
did to explain why I ignored the tail.



Francisco Olarte.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] pgFormatter v2.1 has been released

[Gilles Darold]

pgFormatter 2.1 released
--

Version 2.1 of pgFormatter, a free a SQL formatter/beautifier dedicated
to standard SQL and PostgreSQL specifics keywords, has been officially
released and is publicly available for download.

This release fixes several issues reported by users since four months.
It also adds some improvements in code formatting:

  - Add support to new psql meta-command from v10.
  - Add two command line option to defined where comma must appears
in a parameter list:
   
 -b | --comma-start: in a parameters list, start with a comma (see -e)
 -e | --comma-end  : in a parameters list, end with a comma (default)
   
The CGI interface adds a new checkbox to force comma at beginning.
Default is lines end with a comma.
  - Prevent dynamic code formatting. By default pgFormatter takes all
code between single quote as string constant and do not perform
any formatting on this code. It is common to use a string as
code separator to avoid doubling single quote in dynamic code
generation, in this case pgFormatter can fail to auto detect
the code separator. By default it will search for any string after
the EXECUTE keyword starting with dollar sign. If it can not auto
detect your code separator you can use the command line option -S
or --separator to set the code separator that must be used.
  - Make it possible to run pg_format via symlink. For example, if
pgFormatter is in /opt/pgFormatter and there is a symlink like
/usr/local/bin/pg_format -> /opt/pgFormatter/pg_format
then previous version wouldn't work when called via symlink, as
it would search for libs in /usr/local/bin/lib/, and not in
/opt/pgFormatter/lib.

For the full list of changes, see:

Changelog: https://github.com/darold/pgFormatter/blob/master/ChangeLog


Links & Credits


Thank to the developers who submitted patches and users who reported bugs
and feature requests, especially Alvaro Herrera, fnwiya, Sebastian Albert,
Vesa Karjalainen, Fabian Zeindl, Huy Pham, Jakob Egger and Gajus Kuizinas

pgFormatter is an open project. Any contribution to build a better tool is
welcome. You just have to send your ideas, features requests or patches
using the GitHub tools.

Links:

Website: http://sqlformat.darold.net/
Download1: https://github.com/darold/pgFormatter/releases/
Download2: http://sourceforge.net/projects/pgformatter/
Development: https://github.com/darold/pgFormatter

About pgFormatter
-

pgFormatter is a SQL formatter/beautifier that supports keywords from
SQL-92, SQL-99, SQL-2003, SQL-2008, SQL-2011 and PostgreSQL specifics
keywords. May works with any other databases too. It shares the same
code with pgBadger, so any improvement made in the parser is reversed to
pgBadger. Tool created by Gilles Darold.

pgFormatter can work as a console program or as a CGI. It will
automatically detect his environment and output as text or as HTML
following the context.

pgFormatter works on any platform and is available under the PostgreSQL
licence.

-- 
Gilles Darold



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Numeric numbers

[Олег Самойлов]

On Sat, 2017-09-02 at 18:58 +0200, Francisco Olarte wrote:
> CCing the list ( hint: use reply all in your MUA, otherwhise people
> will loose the thread, this message came only for me. If that was
> what
> you wnated, please indicate so in future messages, as the custom in
> this list is to reply to list + posters )

Got it.

> 
> On Sat, Sep 2, 2017 at 6:21 PM, Олег Самойлов  wrote:
> > 
> > On Sat, 2017-09-02 at 17:54 +0200, Francisco Olarte wrote:
> > > 
> > > It's probably doing 1(integer) => double precioson => numeric(20)
> > > or
> > > something similar if you do not specify.
> > > 
> > > Francisco Olarte.
> > Well, the question was not only about why there is only 20 "3"
> > after
> > point, I suspect this (may be it's not good enough documented, but
> > reasonable), but also about why are there infinite amount of "0"
> > after
> > point if I subtract "3"s.
> Well, I just skipped over the rest of the code. I consider casting to
> unespecified numeric widths a very bad habit and did not want to
> encourage it.
> 
> Francisco Olarte.

There is nothing in documentation that this casting is a very bad
habit. And this is most interesting part, about infinite zeros. Looked
like a bug.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Numeric numbers

[Francisco Olarte]

CCing the list ( hint: use reply all in your MUA, otherwhise people
will loose the thread, this message came only for me. If that was what
you wnated, please indicate so in future messages, as the custom in
this list is to reply to list + posters )

On Sat, Sep 2, 2017 at 6:21 PM, Олег Самойлов  wrote:
> On Sat, 2017-09-02 at 17:54 +0200, Francisco Olarte wrote:
>> It's probably doing 1(integer) => double precioson => numeric(20) or
>> something similar if you do not specify.
>>
>> Francisco Olarte.
>
> Well, the question was not only about why there is only 20 "3" after
> point, I suspect this (may be it's not good enough documented, but
> reasonable), but also about why are there infinite amount of "0" after
> point if I subtract "3"s.

Well, I just skipped over the rest of the code. I consider casting to
unespecified numeric widths a very bad habit and did not want to
encourage it.

Francisco Olarte.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Numeric numbers

[Francisco Olarte]

Vincenzo:

On Sat, Sep 2, 2017 at 6:20 PM, Vincenzo Romano
 wrote:
> And I think Francisco is asking why only 20 digits.

No need to think, I wasn't asking anything.

I'm used to FLOAT ( I think actually DP )numbers being converted to
numeric(,20), and I normally never cast to unspecified numeric
precision ( except for toy one liners and the like ), and I was trying
to show the OP why he got 20.

Francisco Olarte.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Numeric numbers

[Олег Самойлов]

On Sat, 2017-09-02 at 17:54 +0200, Francisco Olarte wrote:
> It's probably doing 1(integer) => double precioson => numeric(20) or
> something similar if you do not specify.
> 
> Francisco Olarte.

Well, the question was not only about why there is only 20 "3" after
point, I suspect this (may be it's not good enough documented, but
reasonable), but also about why are there infinite amount of "0" after
point if I subtract "3"s.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Numeric numbers

[Scott Marlowe]

On Sat, Sep 2, 2017 at 10:10 AM, Melvin Davidson  wrote:
>
>
> On Sat, Sep 2, 2017 at 11:54 AM, Francisco Olarte  
> wrote:
>>
>> On Sat, Sep 2, 2017 at 4:16 PM, Олег Самойлов  wrote:
>> > Hi all. I have silly question. Look at "numeric" type. According to
>> > docs it must be "up to 131072 digits before the decimal point; up to
>> > 16383 digits after the decimal point". Well, lets see.
>> >
>> > => select 1::numeric/3;
>> > ?column?
>> > 
>> >  0.
>>
>> => select 1::numeric(100,90)/3;
>>?column?
>> --
>>  
>> 0.33
>> (1 row)
>>
>> It's probably doing 1(integer) => double precioson => numeric(20) or
>> something similar if you do not specify.
>>
>> Francisco Olarte.
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
>
> Franciso,
>
> Per the docs, is is not "must be', it is "up to 131072 digits before the 
> decimal point; up to 16383 digits after the decimal point".
> https://www.postgresql.org/docs/9.6/static/datatype-numeric.html#DATATYPE-NUMERIC-TABLE
>
> YOU have specified a precision of numeric(100,90), which means 90 decimals 
> and that is exactly what you got!
> The result is correct, so what is your question?
>
>

Huh. I'm guessing that the cast is the limit here:

smarlowe=# select 1::numeric(1001,500);
ERROR:  NUMERIC precision 1001 must be between 1 and 1000
LINE 1: select 1::numeric(1001,500);


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Numeric numbers

[Vincenzo Romano]

2017-09-02 18:10 GMT+02:00 Melvin Davidson :

>
> On Sat, Sep 2, 2017 at 11:54 AM, Francisco Olarte 
> wrote:
>
>> On Sat, Sep 2, 2017 at 4:16 PM, Олег Самойлов  wrote:
>> > Hi all. I have silly question. Look at "numeric" type. According to
>> > docs it must be "up to 131072 digits before the decimal point; up to
>> > 16383 digits after the decimal point". Well, lets see.
>> >
>> > => select 1::numeric/3;
>> > ?column?
>> > 
>> >  0.
>>
>> => select 1::numeric(100,90)/3;
>>?column?
>> 
>> --
>>  0.3
>> 3
>> (1 row)
>>
>> It's probably doing 1(integer) => double precioson => numeric(20) or
>> something similar if you do not specify.
>>
>> Francisco Olarte.
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>>
>
>
>
> *Franciso,*
> *Per the docs, is is not "must be', it is "up to 131072 digits before the
> decimal point; up to 16383 digits after the decimal point".*
>
> *https://www.postgresql.org/docs/9.6/static/datatype-numeric.html#DATATYPE-NUMERIC-TABLE
> *
>
> *YOU have specified a precision of numeric(100,90), which means 90
> decimals and that is exactly what you got!*
>
> *The result is correct, so what is your question?*
>
> --
> *Melvin Davidson*
> I reserve the right to fantasize.  Whether or not you
> wish to share my fantasy is entirely up to you.
>


The original snippet reads:

select 1::numeric/3;

And I think Francisco is asking why only 20 digits.

-- 
Vincenzo Romano - NotOrAnd.IT
Information Technologies
--
NON QVIETIS MARIBVS NAVTA PERITVS

Re: [GENERAL] Numeric numbers

[Vincenzo Romano]

Quoting from documentation:

"without any precision or scale [you get] a column in which values of any
precision and scale can be stored, up to the implementation limit on
precision."

I suspect the cast is doing some precision limitation.

--
Vincenzo Romano - NotOrAnd.IT
Information Technologies
--
NON QVIETIS MARIBVS NAVTA PERITVS

Il 02 set 2017 17:57, "Francisco Olarte"  ha
scritto:

> On Sat, Sep 2, 2017 at 4:16 PM, Олег Самойлов  wrote:
> > Hi all. I have silly question. Look at "numeric" type. According to
> > docs it must be "up to 131072 digits before the decimal point; up to
> > 16383 digits after the decimal point". Well, lets see.
> >
> > => select 1::numeric/3;
> > ?column?
> > 
> >  0.
>
> => select 1::numeric(100,90)/3;
>?column?
> 
> --
>  0.
> 33
> (1 row)
>
> It's probably doing 1(integer) => double precioson => numeric(20) or
> something similar if you do not specify.
>
> Francisco Olarte.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Re: [GENERAL] Numeric numbers

[Melvin Davidson]

On Sat, Sep 2, 2017 at 11:54 AM, Francisco Olarte 
wrote:

> On Sat, Sep 2, 2017 at 4:16 PM, Олег Самойлов  wrote:
> > Hi all. I have silly question. Look at "numeric" type. According to
> > docs it must be "up to 131072 digits before the decimal point; up to
> > 16383 digits after the decimal point". Well, lets see.
> >
> > => select 1::numeric/3;
> > ?column?
> > 
> >  0.
>
> => select 1::numeric(100,90)/3;
>?column?
> 
> --
>  0.
> 33
> (1 row)
>
> It's probably doing 1(integer) => double precioson => numeric(20) or
> something similar if you do not specify.
>
> Francisco Olarte.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



*Franciso,*
*Per the docs, is is not "must be', it is "up to 131072 digits before the
decimal point; up to 16383 digits after the decimal point".*

*https://www.postgresql.org/docs/9.6/static/datatype-numeric.html#DATATYPE-NUMERIC-TABLE
*

*YOU have specified a precision of numeric(100,90), which means 90 decimals
and that is exactly what you got!*

*The result is correct, so what is your question?*

-- 
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

Re: [GENERAL] Numeric numbers

[Francisco Olarte]

On Sat, Sep 2, 2017 at 4:16 PM, Олег Самойлов  wrote:
> Hi all. I have silly question. Look at "numeric" type. According to
> docs it must be "up to 131072 digits before the decimal point; up to
> 16383 digits after the decimal point". Well, lets see.
>
> => select 1::numeric/3;
> ?column?
> 
>  0.

=> select 1::numeric(100,90)/3;
   ?column?
--
 
0.33
(1 row)

It's probably doing 1(integer) => double precioson => numeric(20) or
something similar if you do not specify.

Francisco Olarte.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Numeric numbers

[Олег Самойлов]

Hi all. I have silly question. Look at "numeric" type. According to
docs it must be "up to 131072 digits before the decimal point; up to
16383 digits after the decimal point". Well, lets see.

=> select 1::numeric/3;
?column?

 0.

Well, I expect 16383 digits after ".". But nope.
=> select (1::numeric/3-0.)*1e20;
?column?

 0.
=> select (1::numeric/3-0.3332)*1e20;
?column?

 1.

There is only 20 "3" after ".". Well, may be this is not a problem, but
why are they infinite number of "0" after the point? I can write even

=> select (1::numeric/3-0.)*1e10;
?column?        

 0.

Result the same. According to the docs: "Numeric values are physically
stored without any extra leading or trailing zeroes."


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general