Re: lexing small ints as int2

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of vie sep 03 19:36:06 -0400 2010:
>> On the whole I'm still afraid that changing the initial typing of
>> integer constants is going to break a lot of code while buying not much.
>> Do you have a specific reason for reopening the issue? Or is your
>> concern something different?

> The problem I'm facing is functions declared to take type smallint not
> working unless the integer literal has an explicit cast. Currently the
> best answer is simply to avoid using smallint in functions, but this
> isn't completely satisfying.

Agreed, but there's a very small limit to how much I'm willing to break
to fix that, because it seems like just an annoyance rather than any
significant functionality or performance limitation.

I'm not certain whether that 2002 message described all the types of
problems I saw in the regression test failures. (It might be worth
trying the experiment again, even if that was a complete catalog then.)
But for the sake of argument let's suppose that we just have these
two problems to fix:

1. Not failing when a smallint constant is used and there are
both int4 and int8 potential matches.

I experimented just now with whether this could be fixed by labeling
int4 as a preferred type. That turns out to have some bad consequences
though: the regression tests show failures on cases like VALUES (1),(1.2)
because select_common_type thinks it should resolve to int4 rather than
numeric. With the current semantics of preferred types, it seems to be
a bad idea to label something a preferred type unless everything in its
type category can be implicitly cast to it. (Which again brings up the
question of whether we need the concept at all...) We could maybe get
around that by rejiggering the way that the type resolution rules make
use of preferred types, but the further we go the more likely it is
we'll break applications.

2. Not causing cases like "select 256*256" to throw overflow errors
when they didn't before.

In 2002 I suggested attacking this by dropping the int2 arithmetic
operators. Today I'd suggest keeping them but making them deliver int4,
so that they can't report overflow. Either way, there's some risk
of changing the behavior seen by applications that do arithmetic on
int2 columns. For example, foo(int2a + int2b) will currently call
foo(int2) if it exists, but that would no longer happen. That might
well be a corner-y enough case to pass as acceptable collateral damage
--- except that if the whole reason for doing this is to eliminate
surprising failures to call functions taking int2, breaking a case
like that that used to work hardly seems like an acceptable tradeoff.

So it all looks pretty messy, and any fix carries considerable risk
of changing behaviors that existing applications depend on. Without
some new idea(s) that I'm not seeing now, it doesn't seem like it'd
be worth taking the risk.

regards, tom lane