Re: anyarray

On 2/13/15 10:20 AM, Teodor Sigaev wrote:
> Some of users of intarray contrib module wish to use its features with
> another kind of arrays, not only for int4 type. Suggested module
> generalizes intarray over other (not all) types op pgsql.
>
> Anyarray also provides a calculation of similarity two one dimensinal
> arrays similar to smlar module. Anyarray module doesn't provide an
> something similar to query_int feature of intarray, because this feature
> is very hard to implement (it requires new pseudo-type anyquery), it is
> close to impossible to have operation extensibility and it's complicated
> queries are hidden from pgsql's optimizer (like to jsquery). As far I
> know, query_int isn't very popular for now.

intarray has its uses, so it's not hard to believe that someone will
want, say, a bigint array instead. So generalizing this is useful.

I think this module should be merged with the intarray module. Having
two modules with very similar functionality would be confusing.

Moreover, the two modules provide almost, but not quite, the same set of
operators. You mentioned that the query stuff is probably not that
useful, but the overlaps, contains, and contained operators probably
are, and they look like they could be generalized.

I'm not sure about the similarity stuff. No explanation or
documentation is provided for what it's useful for or what method to choose.

GiST and GIN support is only provided for a finite set of built-in
types, and there is no documentation for how to extend this to other
types. The GiST and GIN support is the main point of intarray. If
anyarray can only support a finite set of hardcoded types, then it's not
really that "any".

If we can't do better, then I'd rather update the intarray module to
provide polymorphic functions and add index support for, say, bigint and
any other type that a good case can be made for. I don't think
_money_aa_ops for example is going to have many users.