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
No comments:
Post a Comment