Corey Horton <chort...@austin.rr.com> writes: > I'm trying to use array_to_string on the pg_stats column > histogram_bounds... > test83=# select array_to_string(histogram_bounds::anyarray, '-') from > pg_stats where attname = 'id' and tablename = 'widgets'; > ERROR: argument declared "anyarray" is not an array but type anyarray > In 8.1, it worked fine...
Hmm. This seems to have been broken in this patch: http://archives.postgresql.org/pgsql-committers/2008-01/msg00173.php which was in response to this complaint: http://archives.postgresql.org/pgsql-bugs/2008-01/msg00029.php and was attempting to prevent that same failure message in a different context :-(. I guess we forgot that pg_statistic makes it possible that the *actual* datatype passed to a function could be anyarray. While we could probably revert just enough of the changes to enforce_generic_type_consistency to allow this case again, I wonder just how safe that'd really be. It would amount to expecting that functions that take anyarray but don't take or return anyelement to not only work on any array type, but to be always prepared for the input element type to change on-the-fly (since that's exactly what would happen when scanning pg_statistic). Quite a lot of the built-in anyarray functions are prepared to do that, but I'm not sure they all are. Are we prepared to re-open what could be at least a risk of crashing bugs, in order to support this type of usage? I have to admit that it's nice to be able to process the pg_statistic columns like this --- I've done it myself. And we'd not heard any reports of problems with it before 8.3. regards, tom lane -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql