I wrote:
> ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
>> I hope anyelement could be used in cast because casts are supported by
>> almost programming languages where template or generics are available.
> I think what you're suggesting is that inside a polymorphic function,
> anyelement would somehow be a macro for the type that the function's
> current anyelement parameter(s) have. It's an interesting idea but
> it's just fantasy at the moment; I don't even have an idea of how we
> might implement that.
After thinking about it for awhile, I don't like the notation anyway
--- it's not immediately obvious that a cast to anyelement should mean
something like that. What seems more sensible to me is to introduce
a function to get the type of an expression, so that you could write
something like
cast(expression as typeof(expression))
This special function would act like C's sizeof and similar constructs
in that its argument would never be evaluated, only inspected at parse
time to determine its type. (There are already precedents for this in
SQL; see the IS OF construct.) So the original requirement would be
met with something like "expression::typeof($1)".
A small disadvantage of this approach is that it's notationally a bit
uglier for anyelement/anyarray pairs. For example, consider a function
"foo(anyelement) returns anyarray". To get at the element type you just
say typeof($1), but if you have to name the array type you need a hack
like typeof(array[$1]). In the other direction (name the element type
of a parameter array) something like typeof($1[1]) would work.
The countervailing advantage is that this solves a lot of problems that
overloading anyelement wouldn't ever solve, since you can get at the
type of any expression not just a bare parameter.
Also I think it'd be relatively easy to stick into the parser; it
wouldn't require introduction of any new parse-time context information.
Anyway, none of this is material for 8.4, just a possible TODO item.
regards, tom lane