The parser has some heuristics to try to match up existing functions and
operators when not all types are known apriori. We've had this
capability since v6.4, with some modest evolution since then.
Currently, if there is more than one function, say, which *could* match
the specified query, and if the arguments with unspecified types
(typically looking like a bare SQL9x string) come from different
"categories" of types (e.g. integer and string, or float and date) then
the parser throws an error about not finding the function.
I propose that we modify the heuristic slightly, so that if there are
function matches with arguments from different categories, and if one or
more of the possible matches comes from the "string" category, then that
category is preferred.
There are two good reasons for this, and one bad reason ;) :
1) the original query carries "string" semantics, so it is a reasonable
fallback interpretation for the query.
2) a string fallback will make things like
select tstampfield at time zone 'pst' from t1;
and
select tstampfield at time zone interval '-08:00' from t1;
possible (oh, btw, I've got patches to implement "at time zone..."),
where currently
select tstampfield at time zone 'pst' from t1;
fails and requires that 'pst' be specified as "text 'pst'".
3) some braindead "compatibility tests" from some competing open-source
database projects have poorly designed queries which interpret this lack
of fallback as a lack of support for database features. So instead of
getting extra points for having *more* capabilities in a particular
area, they claim that we don't support anything in that area. Most
annoying, and it is not likely to change.
Comments? I've got code which implements the fallback for functions, and
presumably the same for operators will be easy to do...
- Thomas