Tom Lane <[EMAIL PROTECTED]> writes: > Mark Dilger <[EMAIL PROTECTED]> writes: > > ... The argument made upthread that a > > quadratic number of conversion operators is necessitated doesn't seem > > right to me, given that each type could upcast to the canonical built in > > type. (int1 => smallint, int3 => integer, ascii1 => text, ascii2 => > > text, ascii3 => text, etc.) > > This would work all right for the string-category cases, since TEXT is > the only thing you really care about having them cast to anyway. > It probably won't work all that well for int1/int3, because you really > want them to coerce implicitly to all the "wider" numeric types. > Otherwise, perfectly sane queries like "int8 + int1" fail.
Actually that one works, you get numeric addition which then would get cast back to an int8 if you tried to store it in an int8 column. Not necessarily the most efficient way to go about it though. However you do have to provide all the cross-data-type comparisons if you want indexes to work right and that alone gives you a couple hundred catalog entries. > Part of the issue here is that we deliberately keep the parser from > searching for multi-step coercions. So for example if you only provide > int1->int2 then the existence of up-casts from int2 doesn't help you > use an int1 with anything except int2. After my initial plea for multi-step coercions I've thought about it a bit further and I think I can make a stronger case for them now: Consider that in the current situation there's an asymmetry between function calls and casts. If you call a function and there's an implicit cast that matches the argument then we'll use it. But if you use a cast implemented with that same function it won't work. For example say you implement a numeric data type called mynumber and you define function mynumber(numeric) => mynumber and use it to implement the cast numeric::mynumber. You'll find mynumber(integer) works just fine but integer::mynumber doesn't. To make the situation parallel we would had to find two-step casts only for explicit casts and if and only if the intermediate cast is an implicit cast. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
