Re: btree_gin and btree_gist for enums

>> 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?