Re: Proposal for resolving casting issues

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Proposal for resolving casting issues
Дата
Msg-id 18914.1032366401@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Proposal for resolving casting issues  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
Список pgsql-hackers
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> Note that if you write, say,
> set numericcol = numericcol * 3.14159;
> my proposal would do the "right thing" since the constant would be typed
> as numeric to start with and would stay that way.  To do what you want
> with a float variable, it'd be necessary to write
> set numericcol = numericcol * float4col::numeric;

> Yes, that is the case where the new behavior would imho not be good (but you 
> say spec compliant). I loose precision even though there is room to hold it.

Lose what precision?  It seems silly to imagine that the product of
a numeric and a float4 is good to more digits than there are in the
float4.  This is exactly the spec's point: combining an exact and an
approximate input will give you an approximate result.

(Unless of course the value in the float4 happens to be exact, eg,
an integer of not very many digits.  But if you are relying on that
to be true, why aren't you using an exact format for storing it?)

> Informix does the calculations in numeric, and then converts the result
> if no casts are supplied (would do set float4col = float4(float4col::numeric * numericcol)).

I am not sure what the argument is for following Informix's lead rather
than the standard's lead; especially when Informix evidently doesn't
understand numerical analysis ;-)
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Zeugswetter Andreas SB SD"
Дата:
Сообщение: Re: Proposal for resolving casting issues
Следующее
От: Neil Conway
Дата:
Сообщение: Re: genetic algorithm in PostgreSQL