Re: [HACKERS] anyarray

2015-03-05 Thread Peter Eisentraut
On 3/4/15 10:28 PM, Tom Lane wrote:
 Peter Eisentraut pete...@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.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] anyarray

2015-03-05 Thread Andrew Dunstan


On 03/04/2015 10:28 PM, Tom Lane wrote:

Peter Eisentraut pete...@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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] anyarray

2015-03-04 Thread Peter Eisentraut
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.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] anyarray

2015-03-04 Thread Tom Lane
Peter Eisentraut pete...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] anyarray

2015-02-18 Thread Tomas Vondra
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 Vondrahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] anyarray

2015-02-18 Thread Tomas Vondra
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 Vondrahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers