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.


---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?

Reply via email to