From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Expression indexes and casts |
Date: | 2004-03-09 16:18:44 |
Message-ID: | 25816.1078849124@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2004-03-09 16:53:26 | Re: a group of superuser |
Previous Message | Shalu Gupta | 2004-03-09 16:07:13 | dontExecute Flag |