From: | Sim Zacks <sim(at)compulab(dot)co(dot)il> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org, Sandy Oz <alexandra(at)compulab(dot)co(dot)il> |
Subject: | Re: numeric cast oddity |
Date: | 2009-12-06 05:57:54 |
Message-ID: | 4B1B47E2.2000206@compulab.co.il |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Wolfgang Keller | 2009-12-06 11:08:37 | postgresql_autodoc in Python? |
Previous Message | Scott Marlowe | 2009-12-06 03:13:25 | Re: Error in crosstab using date_trunc |