Thinking about this further, it occurs to me that there's no hard reason plpgsql (and other PLs that adopt the we-can-convert-anything-to-string philosophy, such as pltcl) couldn't allow arguments (though not results) of type ANY. It's not different from accepting ANYELEMENT as far as the runtime mechanisms are concerned. The only difference is in constraining multiple arguments and/or the result to be of the same or related types, which is not really an issue that affects the PL directly.Advertising
True. As long as the function has access to the runtime data type, it has the ability to deal with anything it's handed.
As far as the other point goes, I plan to change resolve_type to be like
OK, that all makes good sense to me now.
I'm still not convinced that there is any application for it outside of deriving a polymorphic aggregate's state type, though.
At least not yet ;-)
Between this discussion, and Peter pointing out that the spec allows arrays-of-arrays, it's gotten me thinking about how to implement said arrays-of-arrays. Obviously not gonna happen for 7.4, but I might try to do that, fix the NULL array element issue, and otherwise try to continue the progress on SQL99 array support for 7.5.
Joe
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
