Re: BUG #6530: intarray documentation could do with a warning about operators
От | Robert Haas |
---|---|
Тема | Re: BUG #6530: intarray documentation could do with a warning about operators |
Дата | |
Msg-id | CA+TgmoaMqMJBpONW9HRhH95yidzjvf1EjF-oVgmFFD_ReFnKAQ@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #6530: intarray documentation could do with a warning about operators (kontakt@sandberg-consult.dk) |
Ответы |
Re: BUG #6530: intarray documentation could do with a warning about operators
|
Список | pgsql-bugs |
On Tue, Mar 13, 2012 at 1:12 PM, <kontakt@sandberg-consult.dk> wrote: > The following bug has been logged on the website: > > Bug reference: =A0 =A0 =A06530 > Logged by: =A0 =A0 =A0 =A0 =A0Kasper Sandberg > Email address: =A0 =A0 =A0kontakt@sandberg-consult.dk > PostgreSQL version: 9.1.3 > Operating system: =A0 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 caus= e - > intarray, which i had just imported into my schema. I think it would be n= ice > 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 <literal>&&</>, <literal>@></> and <literal><@</> are equivalent to <productname>PostgreSQL</>'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 arr= ay 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. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: