Tom Lane wrote:
> 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.
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
