Re: AW: type conversion discussion
От | Peter Eisentraut |
---|---|
Тема | Re: AW: type conversion discussion |
Дата | |
Msg-id | Pine.LNX.4.21.0005171527040.349-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: AW: type conversion discussion (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: AW: type conversion discussion
|
Список | pgsql-hackers |
Tom Lane writes: > perhaps we want > > int2 -> int4 -> int8 -> numeric -> float8 > float4 -> float8 In a parallel email you mentioned that your promotion tree idea will give the system well-understood (single) inheritance semantics, with which I agree 100%. But that is only true if the upward conversion always works, which it won't because not every numeric "is-a" float8, and strictly speaking, neither is int8. This is unclean at best, but might even cause genuine failures if some promotion metric decided on a float8 function over a numeric function because it would generate the "least casting" on the other function attributes. So it would have to be more like this int2 -> int4 -> int8 -> numericfloat4 -> float8 -> numeric This tree is "correct" in the above sense but has a number of obvious problems. float[x] + numeric would now yield numeric. The solution is making an explicit float8+numeric function. Okay, so at the end it's actually more like 8 functions, but that's a price I'd be willing to pay. (Perhaps the commutator mechanism could be extended to cover different types as well.) Incidentally, this would also enable some cases to work that wouldn't now, e.g. if N is a numeric outside the range of float8 and F is some float8, then N - F would currently fail, but it need not, depending on how it's implemented. The other problem is that integers would never implicitly be promoted to floats. This is sensible behaviour from a numerical analysis point of view but probably not acceptable for many. However, given that there is numeric, any int/float operations would be promoted to numeric/numeric, which is in any case the right thing to do. The only thing is to provide numeric functions. The alternative is to use a non-tree lattice for type promotion - float4 -- float8 - / / \ int2 --- int4 ---- int8 ----- numeric but that would introduce a world of problems which we probably best avoid (as long as possible). > That's still not entirely satisfactory because simple examples like > > WHERE float4var < 4.4; > > won't be done the way we want: the constant will promote to float8 > and then you'll get float4var::float8 < 4.4::float8 which is not > able to use a float4 index. Could this do it? unknownnumeric -> float4 -> float8 -> numeric (Assuming `unknownnumeric' only represents literals with decimal points. Others should probably be the "best fit" integer type.) -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Peter EisentrautДата:
Сообщение: Re: Proposal for fixing numeric type-resolution issues