So, in reading these patches, it came to me that we might want to have pg_upgrade mark indexes invalid if we in the future change the implementation of some opclass. For instance, the inclusion opclass submitted here uses three columns: the indexed value itself, plus two booleans; each of these booleans is a workaround for some nasty design decision in the underlying datatypes.
One boolean is "unmergeable": if a block range contains both IPv4 and IPv6 addresses, we mark it as 'unmergeable' and then every query needs to visit that block range always. The other boolean is "contains empty" and is used for range types: it is set if the empty value is present somewhere in the block range. If in the future, for instance, we come up with a way to store the ipv4 plus ipv6 info, we will want to change the page format. If we add a page version to the metapage, we can detect the change at pg_upgrade time and force a reindex of the index. Thoughts? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers