Re: numeric cast oddity - Mailing list pgsql-general

From Sim Zacks
Subject Re: numeric cast oddity
Date
Msg-id 4B1B47E2.2000206@compulab.co.il
Whole thread Raw
In response to Re: numeric cast oddity  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: numeric cast oddity
List pgsql-general
As I mentioned, it is more then just a headers issue it is a type issue.

I have a view that has a column of type numeric(20,4)

If I replace that column with -1::numeric(20,4) or - (1::numeric(20,4))
the type that goes to the view is numeric without any scale or precision
and then I get an error that I cannot change the column type.

It seems to be a negative number issue because if I use a positive
number or null it gives me the numeric(20,4) it is only for negative
that it gives me the numeric without scale or precision.


Sim



Tom Lane wrote:

> I wrote:
>
>> which are indeed different (might be worth looking into why)
>>
>
> Oh: the reason they're different is that these expressions are not
> actually the same thing.  Minus binds less tightly than typecast.
> You get consistent results if you input equivalent expressions:
>
> regression=# select cast(-1 as numeric(20,4));
>  numeric
> ---------
>  -1.0000
> (1 row)
>
> regression=# select (-1)::numeric(20,4);
>  numeric
> ---------
>  -1.0000
> (1 row)
>
> regression=# select - cast(1 as numeric(20,4));
>  ?column?
> ----------
>   -1.0000
> (1 row)
>
> regression=# select - 1::numeric(20,4);
>  ?column?
> ----------
>   -1.0000
> (1 row)
>
> What we're actually seeing here is that the code to guess a default
> column name doesn't descend through a unary minus operator, it just
> punts upon finding an Op node.
>
>             regards, tom lane
>

pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Error in crosstab using date_trunc
Next
From: Alban Hertroys
Date:
Subject: Re: Error in crosstab using date_trunc