Joshua Burns wrote
> DROP FUNCTION IF EXISTS anyar_anyel(anyarray);
> CREATE OR REPLACE FUNCTION anyar_anyel(anyarray) RETURNS anyelement AS
> $BODY$
> BEGIN
> RETURN $1;
> END;
> $BODY$ LANGUAGE plpgsql;
Similar to my comment on anyelement->anyarray:
The original goal here is to reduce dimensionality. In the simple case an
array with a base type is required as input and the output is a scalar
having the same base type.
For both of these the most common usage is to go between 0-dim. and 1-dim.
In theory this limited behavior should probably be restricted to
"anynonarray->anyarray" and vice-versa while the anyelement variations can
allow the more permissive/flexible check of identical base types.
Again, hopefully this is educational. I'm going from the described behavior
and my general understanding of how things work. I am not familiar with the
source code nor the design considerations that preceded its creation.
I'm not sure any real conclusions/goals can be drawn absent something more
specific than example queries. The behavior described (up/down-grading
between 1-dim arrays and scalar values) explains away all your "unexpected"
results. But your expectations are not unreasonable - just not commonly
used/needed in practice; or if they are someone else has a
solution/work-around I am not familiar with.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Odd-behavior-in-functions-w-anyarray-anyelement-tp5770537p5770556.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.