>> 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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
