Re: Expression indexes and casts
От | Tom Lane |
---|---|
Тема | Re: Expression indexes and casts |
Дата | |
Msg-id | 25816.1078849124@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Expression indexes and casts (Stephan Szabo <sszabo@megazone.bigpanda.com>) |
Ответы |
Re: Expression indexes and casts
|
Список | pgsql-general |
Stephan Szabo <sszabo@megazone.bigpanda.com> writes: > I haven't done any looking around yet (about to head off to work), but it > looks like in the case where the system decides to cast a to text in order > to get a working equality, the index isn't used, whereas in the case where > I explicitly cast it, it can. I think the problem is that explicit and implicit casts are marked differently in the cast parse node, causing equal() to consider the two expressions different. There is currently a hack involving a "don't care" setting for this field, but it doesn't help you. I wonder if it would be better to make equal() explicitly ignore the cast-type field. It seems like that could break other things though :-(. A narrower patch would be to change the cast type field to don't-care in the copy of the parse tree that is made for planner user. [ thinks some more... ] On the other hand, there are cases where explicit and implicit casting are actually semantically different (think varchar() and char() length constraints). Maybe the don't-care business is itself a bug, and you're just stuck. regards, tom lane
В списке pgsql-general по дате отправления: