2009/2/17 Tom Lane <t...@sss.pgh.pa.us>: > I wrote: >> ITAGAKI Takahiro <itagaki.takah...@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.
it's look like good idea regards Pavel Stehule > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers