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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
