Robert Haas <robertmh...@gmail.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.
This ties in to the comment Peter made about the "conversion distance"
idea in that 2002 thread: there's no obvious principled way to assign
the distances, and arbitrarily-chosen distances will lead to arbitrary
behaviors.
Anyway, if you think you can come up with something workable, have at
it. I'm just here to tell you it's not as easy as it looks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
