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,
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
ist is to reply to list + posters )
Got it.
>
> On Sat, Sep 2, 2017 at 6:21 PM, Олег Самойлов <ol...@mipt.ru> wrote:
> >
> > On Sat, 2017-09-02 at 17:54 +0200, Francisco Olarte wrote:
> > >
> > > It's probably doing 1(integer) => double precios
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;
> >
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)
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
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
