Re: BUG #6092: specific casting required for gist indexing of bigint
От | Tom Lane |
---|---|
Тема | Re: BUG #6092: specific casting required for gist indexing of bigint |
Дата | |
Msg-id | 25123.1309979805@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #6092: specific casting required for gist indexing of bigint (Jeff Frost <jeff@pgexperts.com>) |
Список | pgsql-bugs |
Jeff Frost <jeff@pgexperts.com> writes: > On 07/05/11 17:06, Tom Lane wrote: >> "Jeff Frost" <jeff@pgexperts.com> writes: >>> Ran into a situation with a customer who is using the btree_gist contrib >>> module to allow combined index of some tsearch data and two other columns. >>> One of these other columns is a bigint field. I noticed that the combined >>> index won't be used by the planner unless you specifically cast the bare >>> number to a bigint. >> If memory serves, the btree_gist opclasses don't include any cross-type >> operators, so "int8 = int4" doesn't work here. > Ah! And if you look at the contrib/btree_gist/sql/int8.sql test file, you'll > see this: > SELECT count(*) FROM int8tmp WHERE a < 464571291354841::int8; > So, I'd say it's expected behavior even though it's slightly counter intuitive > if you're used to the auto typing behavior. Well, it might be nice to fix it sometime, but I'd characterize it as an unimplemented feature in btree_gist, not a bug. regards, tom lane
В списке pgsql-bugs по дате отправления: