Tom Lane wrote:
> Thomas Hallgren <thomas@tada.se> writes:
>
>> - Why does PostgreSQL declare three different generic types? Isn't one
>> enough? ISTM it would be far simpler to use constructs like 'any' and
>> 'any[]' but neither of them are permitted.
>>
>
> "any" isn't the same as "anyelement", because it doesn't have the
> property of constraining different argument positions to be the same
> type. For instance, compare(any,any) and compare(anyelement,anyelement)
> would accept different sets of input types.
>
>
I've read that the "anyelement" will constrain all parameters and the
return type to be of the same type, or an array of that type. I
understand that concept since it will give the executor an ability to
infer the return type by looking at the parameters. If "any" doesn't do
that then I understand the difference.
I've been trying to use "any" with no luck. How do I declare a function
that takes an "any" as a parameter? I know how it would be implemented
internally but the SQL for it eludes me.
I realize that it would be trickier to return an "any" since the
expected return type must somehow be derived from the context where the
function was called. But similar things are done with "record" already,
right?
>> - Why can't I write 'anyelement[]'. Shouldn't that be the same thing as
>> 'anyarray'?
>>
>
> No, you're confusing these with actual datatypes. They are pseudotypes,
> which means they're only allowed as function argument/result type
> placeholders.
>
>
I understand that. But I'd consider it an implementation detail and I
think the average SQL user finds it a bit confusing. Wouldn't it be a
good idea to let the SQL parser recognize the anyelement[] construct as
a synonym for anyarray? I.e. allow me to write:
CREATE FUNCTION makeSingleElementArray(anyelement) RETURNS anyelement[]
AS ...
Regards,
Thomas Hallgren
PS. I'm happy to announce that PL/Java now handles records, domains,
user defined types, anyelement, and anyarray without problems.
