Re: lexing small ints as int2
От | Robert Haas |
---|---|
Тема | Re: lexing small ints as int2 |
Дата | |
Msg-id | AANLkTi=S8TcpKEjRfSrp5QjaPox=w_kHwU2Oz1tiwJax@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: lexing small ints as int2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: lexing small ints as int2
|
Список | pgsql-hackers |
On Sat, Sep 4, 2010 at 12:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@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. 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
В списке pgsql-hackers по дате отправления: