Re: Fixed length data types issue

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Mark Dilger <pgsql(at)markdilger(dot)com> 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