Re: Questions about parsing boolean and casting to anyelement

2009/2/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> I wrote:
>> ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>