Excerpts from Tom Lane's message of mié may 04 17:14:25 -0300 2011:
> Robert Haas <robertmhaas@gmail.com> writes:
> > 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.
>
> 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.
I remember that one of the problems put forth against this idea was that
stuff like int2+int2 which currently returns int2 would have to be
changed to return int4, otherwise it risks overflow which it currently
doesn't (not because the operator would change, but rather because some
expressions would be lexed differently). And so on with other
operators. I am not sure how severe this problem is for users in
practice -- my uneducated guess is that mostly they will not care about
such changes.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
