Re: [BUGS] BUG #6530: intarray documentation could do with a warning about operators
On Tue, Mar 13, 2012 at 1:12 PM, kont...@sandberg-consult.dk wrote: The following bug has been logged on the website: Bug reference: 6530 Logged by: Kasper Sandberg Email address: kont...@sandberg-consult.dk PostgreSQL version: 9.1.3 Operating system: Debian squeeze Description: Hello. I recently had a problem with array operators and @ on my gin index, it failed. Friendly people on #postgresql helped me track down the root cause - intarray, which i had just imported into my schema. I think it would be nice if the documentation for intarray on the documentations page had a short warning about this, so people can import into other schemas if they need to use the default array operators. Thanks. We do have this: para The operators literalamp;amp;/, literal@gt;/ and literallt;@/ are equivalent to productnamePostgreSQL/'s built-in operators of the same names, except that they work only on integer arrays that do not contain nulls, while the built-in operators work for any array type. This restriction makes them faster than the built-in operators in many cases. /para But maybe some more explicit warning is needed. Not sure exactly what. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6530: intarray documentation could do with a warning about operators
Robert Haas robertmh...@gmail.com writes: We do have this: para The operators literalamp;amp;/, literal@gt;/ and literallt;@/ are equivalent to productnamePostgreSQL/'s built-in operators of the same names, except that they work only on integer arrays that do not contain nulls, while the built-in operators work for any array type. This restriction makes them faster than the built-in operators in many cases. /para But maybe some more explicit warning is needed. Not sure exactly what. I think the gripe is basically that, while these operators might be equivalent to the built-in ones as far as results go, they are not equivalent in terms of their ability to match to indexes. But not sure how we turn that observation into useful documentation. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6530: intarray documentation could do with a warning about operators
yes, I could not figure out why my GIN index was not used, this is what i meant. On 09/04/12 18:16, Tom Lane wrote: Robert Haasrobertmh...@gmail.com writes: We do have this: para The operatorsliteralamp;amp;/,literal@gt;/ and literallt;@/ are equivalent toproductnamePostgreSQL/'s built-in operators of the same names, except that they work only on integer arrays that do not contain nulls, while the built-in operators work for any array type. This restriction makes them faster than the built-in operators in many cases. /para But maybe some more explicit warning is needed. Not sure exactly what. I think the gripe is basically that, while these operators might be equivalent to the built-in ones as far as results go, they are not equivalent in terms of their ability to match to indexes. But not sure how we turn that observation into useful documentation. regards, tom lane -- Kasper Sandberg Sandberg Enterprises +45 51944242 http://www.sandbergenterprises.dk -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6530: intarray documentation could do with a warning about operators
The following bug has been logged on the website: Bug reference: 6530 Logged by: Kasper Sandberg Email address: kont...@sandberg-consult.dk PostgreSQL version: 9.1.3 Operating system: Debian squeeze Description: Hello. I recently had a problem with array operators and @ on my gin index, it failed. Friendly people on #postgresql helped me track down the root cause - intarray, which i had just imported into my schema. I think it would be nice if the documentation for intarray on the documentations page had a short warning about this, so people can import into other schemas if they need to use the default array operators. Thanks. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
