> There's still the problem that it won't work across a major version > upgrade that makes any change whatsoever to the rowtype of pg_statistic.
I'm sorry if my previous explanation was poor, this time I am going to be detailed. Suppose you want to upgrade from 9.4 to 9.6. In that case you would use the pg_upgrade utility provided by the release 9.6, which means that it's the pg_dump who would have to connect to the older instance and to prepare tuples to be inserted to the pg_statistic of the newer instance. The pg_dump utility would have to convert statistical data to the new format (for example, add placeholders for new columns), so generated INSERT statements would be fine provided that the pg_dump would be up-to-date. The documentation states that we should always run the pg_upgrade binary of the new server, not the old one [http://www.postgresql.org/docs/9.5/static/ pgupgrade.html, Usage, #9]. This means that the pg_upgrade will definitely use a fresh version of pg_dump utility that is aware of all possible pitfalls. Furthermore, each INSERT statement consists of textually-serialized columns of pg_statistic. Columns of 'anyarray' type are deserialized using the 'array_in' procedure which performs various sanity checks, including the element type check. Thus it is not possible to insert an anyarray object which will cause server death. -- Dmitry Ivanov Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
