Joe Conway <mail@joeconway.com> writes:
> Do I have until midnite PDT, or EDT?
We hadn't actually set a formal deadline time AFAIR. Midnight your
local time is fine with me.
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.
As far as the other point goes, I plan to change resolve_type to be like
resolve_polymorphic_type(declared_type, context_actual_type,
context_declared_type)
where context_actual_type is the actual datatype passed to an argument
of declared type context_declared_type, and declared_type is the
declared type of some argument or result that you want to resolve (not
necessarily the same argument). So the rules are
1. declared_type not polymorphic -> return it as-is.
2. declared_type polymorphic, but context_declared_type not polymorphic
-> raise error ("can't resolve").
3. Otherwise there are four possible combinations:
declared_type context_declared_type action
ANYELEMENT ANYELEMENT return context_actual_type
ANYELEMENT ANYARRAY return get_element_type(context_actual_type)
(raise error if it fails)
ANYARRAY ANYELEMENT return get_array_type(context_actual_type)
(raise error if it fails)
ANYARRAY ANYARRAY check context_actual_type is an
array, then return it
This should work as long as the parser has previously done
enforce_generic_type_consistency on the call. I'm still not convinced
that there is any application for it outside of deriving a polymorphic
aggregate's state type, though.
regards, tom lane