I have some questions regarding any, anyelement, and anyarray.
- 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.
- Why isn't the 'anyarray' declared as an array using the elemenent type
'anyelement' in pg_type?
- Why can't I write 'anyelement[]'. Shouldn't that be the same thing as
'anyarray'?
- The 'any' is listed as a type but I get a syntax error whenever I try
to use it. If I could use it, what would be the difference between 'any'
and 'anyelement'? The only thing I can think of is if 'anyelement' was
restricted to non-arrays, but apparently it isn't. I've tried and
there's nothing stopping me from passing an 'int[]' to a function that
takes an 'anyelement'.
Regards,
Thomas Hallgren
Thomas Hallgren <[email protected]> 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.
There's some historical background to this, having to do with the fact
that "any" existed first. Possibly we wouldn't have bothered with "any"
if all had been invented at the same time. But I feel no pressure to
remove "any".
> - Why isn't the 'anyarray' declared as an array using the elemenent type
> 'anyelement' in pg_type?
Because it's a pseudotype, not a type.
> - 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.
regards, tom lane
> Thomas Hallgren <[email protected]> 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.
Thomas Hallgren <[email protected]> writes:
> I've been trying to use "any" with no luck. How do I declare a function
> that takes an "any" as a parameter?
ANY is a reserved word, so to use it as a type name you need quotes:
regression=# create function foo("any") returns int as '' language sql;
ERROR: SQL functions cannot have arguments of type "any"
(This may be another reason why we went for "anyelement" ...)
> 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.
You really can't use "any" as a function result type; it's not sensible
because there's no way to infer an actual type. There are functions for
which an "any" argument type is sensible, eg count(*), but I don't see
a use for this pseudotype as a result type.
> Wouldn't it be a good idea to let the SQL parser recognize the
> anyelement[] construct as a synonym for anyarray?
[ shrug... ] Can't get excited about it. It'd complicate and confuse
the documentation, as well as the code, for zero functional improvement.
I also have a gut feeling that this is really wrong anyhow. anyarray
isn't an array, it's a placeholder.
regards, tom lane
By continuing to browse this website, you agree to the use of cookies. Go to Privacy Policy.
