Re: Prefered Types - Mailing list pgsql-hackers

2011/5/4 Tom Lane <tgl@sss.pgh.pa.us>:
> Perhaps it would be adequate to allow automatic resolution of an
> overloading conflict only when one of the available alternatives
> dominates all others, ie, none of the argument positions requires a
> "longer distance" cast than is used in that position by any other
> available alternative.  I'm just throwing that out as a possibility,
> I haven't tried it.

That works OK for most things, but there's one case where I think we
might need a better solution - suppose A is a subtype of B.  It's
fairly common to define a function or operator f(A,A) and f(B,B), and
to want f(A,B) or f(B,A) to be interpreted as a the latter rather than
the former.  For example, let A=int2, B=int4, f=+.  Now, we can (and
currently do) handle that by just defining all the combinations
explicitly, but people don't always want to do that.

>> It's not clear to me whether in any of this there is a solution to the
>> problem of int2 being a second-class citizen.
>
> I've always felt that the basic problem int2 has got is that the parser
> initially types integer-looking constants as int4 or larger, even if
> they'd fit in int2.  If it typed them as int2 then the unintuitive
> behaviors would largely go away, without any need for allowing implicit
> down-casting from int4 to int2.  I actually tried that once, probably
> close to ten years ago, and it blew up real good because many cases that
> formerly were considered an exact match no longer were, and the parser
> started making some pretty surprising (or at least not backwards
> compatible) resolution choices.  Maybe with a more controllable
> type-promotion mechanism we could get better results there.

Maybe, but I'm not convinced.  I think that's using the lexer to do
the type system's job.  Suppose we add a type uint4, for example: what
then?

> BTW, not to rain on the parade or anything, but I'll bet that
> rejiggering anything at all here will result in whining that puts the
> 8.3-era removal of a few implicit casts to shame.  If the new behavior
> is really significantly better *for users* then we can probably
> withstand the complaints; but if it's just marginal improvements or just
> improves life for hypothetical future extensions, it's not going to fly.

Yeah, I share that fear, which is why I think the idea of generalizing
typispreferred to an integer has more than no merit: it's less likely
to break in ways we can't anticipate.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company