Re: lexing small ints as int2

On Sat, Sep 4, 2010 at 12:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Maybe the lexer isn't the right place to fix this.  The problem here
>> (or so I gather) is that if I say foo(1), then 1 is an integer and
>> we'll do an "implicit" cast to bigint, real, double precision,
>> numeric, oid, or reg*, but the cast to smallint is assignment-only.
>> But I wonder if we shouldn't allow implicit casting anyway when there
>> is a unique best match.  If the only foo(x) function is foo(smallint)
>> and the user tries to call foo with one argument, what else can it
>> mean?
>
> Well, the devil is in the details.  A key point here is that as things
> stand, there isn't a "unique best match" for this example.  foo(smallint)
> isn't an allowable match at all.  We'd have to first define some way of
> making it an allowable match, say that assignment casts are an allowed
> way of matching to a function's or operator's arguments; and then define
> some rules that make sure that that new behavior doesn't break all the
> cases that work now.  For instance, if assignment casts are less
> desirable than implicit casts or exact matches, how much less desirable?
> Is, say, a match involving four exact type matches and one assignment
> cast better or worse than one involving one exact match and four
> implicit casts?  The rules we have for this now are already pretty
> ad-hoc, and I'm afraid they'll get worse fast when there are several
> levels of match.

Yeah, that's a problem. At the same time, I can't help feeling that
we ought to have a goal that if there is only one function with a
particular name that is compatible with the specified number of
arguments, we ought to have a fairly good reason not to call it.

I am not too sure that the distinction between implicit casts and
assignment casts is all that useful; it's not too easy to remember
which casts are of which type, nor is it obvious that the current
catalog entries follow any particularly consistent rule. One idea I
had was to ditch that distinction and instead generalize
typispreferred to a 1-byte integer, typpreference. When there is more
than one candidate, we look for one that is strictly better than all
the others, meaning that it is better than any other candidate in at
least one argument position and at least as good in every argument
position. Better in a given argument position means that either an
exact match rather than not, or a higher typpreference value as among
types in the same category. Then you could fix the smallint case by
giving all the typcategory-N data types ascending typpreference
values: int2, int4, int8, float4, float8, numeric. We'll prefer to
cast up rather than down, but we'll cast try to cast down if the
alternative is to fail outright. If there's no candidate that
dominates all the others, then we complain of ambiguity and give up.

I guess you could also keep the notion of implicit vs. assignment
casts but just make more of them implicit and rely on differing
typpreference values to disambiguate. One big problem in this area is
that it's pretty easy to change things in a way that's not backward
compatible, so it's not really worth changing anything at all unless
we're pretty confident that we've got it right. The whole pg_cast
catalog looks to me like kind of a mess. For example, one unintended
consequence of lexing small integers as int2 would be that
foo(0::bool) would start failing. Why? Because there's an explicit
cast from int to bool, but not from smallint or bigint. There's not
much principle there, just expediency.

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