A few days ago I complained that the lossy-hash-indexes patch needed a better solution for letting catalog/index.c know that hash indexes will really store only hashcodes and not the underlying column type. The current version of the patch puts some hard-wired knowledge into index.c:
/* HACK: make hash always use int4 as storage (really it's uint32) */ if (opclassTup->opcmethod == HASH_AM_OID) keyType = INT4OID; else keyType = opclassTup->opckeytype; which might not exactly be a stop-ship issue but it still seems pretty distasteful. We could avoid the problem if all hash opclasses were marked as having storage type int4, but that seems to just move the problem over to opclass creation --- I doubt we want to insist on user-defined opclasses changing to accommodate this, so we'd have to force this marking internally in CREATE OPERATOR CLASS. The idea that seems most attractive to me at the moment is to add a column to pg_am, probably defined like pg_opclass.opckeytype but applying to all opclasses of the index type. Another possibility is the idea I floated before of adding an AM entry point to let it manipulate the index tupledesc in a more general fashion during CREATE INDEX. However it's unclear how much flexibility that would really buy us given the assumptions that are wired into various places, so I'm thinking it's probably just useless complication. Comments, better ideas? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers