I wrote:
>> I think that we can actually get away (from an implementation point of
>> view) with a column containing arrays of different base types; array_out
>> will still work AFAIR. It's an interesting question though how such a
>> column could reasonably be declared. This ties into your recent
>> investigations into polymorphic array functions, perhaps.
>>
>> Maybe "anyarray" shouldn't be quite so pseudo a pseudotype?
I have committed a fix for these problems that makes pg_statistic's
columns into "anyarray" columns. It turns out that my original concerns
about datatypes without associated array types don't matter --- we can
physically build such an array, regardless of whether we can point to a
pg_type entry that describes it.
This is certainly something of a kluge at the moment, because
pg_statistic is making use of facilities that don't exist at the SQL
level. It gets the job done, but I'd like to see some fuller support
for "anyarray" in future.
regards, tom lane