2012/5/3 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2012/5/3 Tom Lane <tgl@sss.pgh.pa.us>:
>>> This notion of "anytypename" is utterly unworkable anyway; there's no
>>> way for the parser to know soon enough that a given argument position
>>> needs to be read as a type name rather than a normal expression.
>
>> type identifier is same identifier like other - but I have no
>> prototype now, so I don't know if there is some trap
>
> No, it isn't, at least not if you have any ambition to support array
> types for instance; to say nothing of types whose standard names are
> keywords, multiple words, etc. Even if you were willing to restrict the
> feature to only work for simple-identifier type names, the parser would
> have thrown an error for failing to find a column by that name, or else
> would have misinterpreted the type name as a column name, long before
> there is any opportunity to recognize that the argument position is
> an "anytypename" argument.
we can identify a position "anytypename" before raising error - it can
be similar to current identification of PL/pgSQL variables inside
expression. Probably it is too complex for this issue :(
Maybe some keyword can help to us. What do you think about new
operator TYPE that can returns regtype value and can be used together
with polymorphic functions.
CREATE FUNCTION foo(anyregtype, ....)
RETURNS anyelement AS ..
SELECT foo('mytype', ....)
or
SELECT foo(TYPE mytype, ....)
It is little bit cleaner than NULL::type.
Regards
Pavel
>
> regards, tom lane
