>> Here is a patch to add enum support to btree_gin and btree_gist. I didn't >> include distance operations, as I didn't think it terribly important, and >> there isn't a simple way to compute it sanely and efficiently, so no KNN >> support.
I don't think we can implement a meaningful distance operator for enums. > This time including the data file for the gist regression tests. It doesn't apply to HEAD anymore. I have tested it on b12fd41. The GiST part of it doesn't really work. The current patch compares oids. We need to change it to compare enumsortorder. I could make it fail easily: > regression=# create type e as enum ('0', '2', '3'); > CREATE TYPE > regression=# alter type e add value '1' after '0'; > ALTER TYPE > regression=# create table t as select (i % 4)::text::e from > generate_series(0, 100000) as i; > SELECT 100001 > regression=# create index on t using gist (e); > SEGFAULT > +ALTER OPERATOR FAMILY gist_enum_ops USING gist ADD Why don't we just create it with those changes? > + * Use a similar trick to that used for numeric for enums, since we don't Do you mean "similar trick that is used" or "trick similar to numeric"? > + * actually know the leftmost value of any enum without knowing the concrete > + * type, so we use a dummy leftmost value of InvalidOid. > + return DatumGetBool( > + DirectFunctionCall2(enum_gt, > ObjectIdGetDatum(*((const Oid *) a)), ObjectIdGetDatum(*((const Oid *) b))) > + ); Wouldn't it be nice to refactor enum_cmp_internal() to accept typcache and use it there like the rangetypes? -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers