Thread: anyarray
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.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
Attachment
On 13.2.2015 16:20, 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. Hi Teodor, I started reviewing this patch today - first of all, kudos for having 944kB of regression tests in 1MB patch ;-) I've noticed two unrelated files ../src/test/modules/dummy_seclabel/expected/dummy_seclabel.out ../src/test/modules/dummy_seclabel/sql/dummy_seclabel.sql I suppose that's not intentional, right? -- Tomas Vondra http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 19.2.2015 03:14, Tomas Vondra wrote: > > I've noticed two unrelated files Meh, should be "I noticed the patch removes two unrelated files" ... > > ../src/test/modules/dummy_seclabel/expected/dummy_seclabel.out > ../src/test/modules/dummy_seclabel/sql/dummy_seclabel.sql > > I suppose that's not intentional, right? > -- Tomas Vondra http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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.
Peter Eisentraut <peter_e@gmx.net> writes:
> 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.
> I think this module should be merged with the intarray module. Having
> two modules with very similar functionality would be confusing.
Perhaps. I think it would be hard to remove intarray without breaking
things for existing users of it; even if the functionality remains under
another name. And surely we don't want to generalize intarray while
keeping that same name. So it might be hard to get to a clean solution.
Speaking of names, I can't avoid the feeling that it is a seriously bad
idea to name an extension the same thing as an existing core type.
regards, tom lane
On 03/04/2015 10:28 PM, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> 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. >> I think this module should be merged with the intarray module. Having >> two modules with very similar functionality would be confusing. > Perhaps. I think it would be hard to remove intarray without breaking > things for existing users of it; even if the functionality remains under > another name. And surely we don't want to generalize intarray while > keeping that same name. So it might be hard to get to a clean solution. > > Speaking of names, I can't avoid the feeling that it is a seriously bad > idea to name an extension the same thing as an existing core type. > > +1. We have far too much experience already of this type of naming confusion. cheers andrew
On 3/4/15 10:28 PM, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> 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. > >> I think this module should be merged with the intarray module. Having >> two modules with very similar functionality would be confusing. > > Perhaps. I think it would be hard to remove intarray without breaking > things for existing users of it; even if the functionality remains under > another name. And surely we don't want to generalize intarray while > keeping that same name. So it might be hard to get to a clean solution. Maybe we could have the anyarray module (name TBD) install two extensions: one of its own, and one that is named intarray that just pulls anyarray in as a dependency. There are more fundamental questions to be answered about the functionality of this proposal first, however.