Peter Eisentraut <peter_e@gmx.net> writes:
> What I had in mind was to allow type conversion between the same
> TypeCategory(). The SQL function analyzer is extraordinarily picky:
I just finished looking at that. It'd be possible (and probably
reasonable) to accept a binary-compatible datatype rather than requiring
exact equality; this would fix your varchar-vs-text example. However,
inserting any runtime type conversion would require a significant amount
of code added. We couldn't do it just by inserting the conversion
function call into the SELECT querytree, because that'd alter the SELECT
semantics, if not actively crash it --- an example of a likely crash is
create function mymax() returns int4 as ' select int8col from tab order by int8col desc limit 1'language sql;
Here, the prepared parsetree is already set up to apply int8 sorting to
the first column of its result. If we try to insert a cast-to-int4,
we will end up sorting int4 data with int8 operators -- instant
coredump.
So the conversion function application would have to be done at runtime
in the SQL function manager, which is more code than I care to take on
at the moment.
Note also that there is code in there to figure out whether a targetlist
satisfies a tuple return datatype; should we also apply automatic type
conversion to elements of such a list? It's getting to be more of a
stretch to say that this is being helpful rather than masking programmer
error.
But binary compatibility is easy. Shall we do that?
regards, tom lane