Re: [HACKERS] Re: type coersion (was OR clause status)

> > I just tried adding the extra line, and initdb failed.  I wonder if we
> > remove the oideqint4, if the parser will go for oideq?
>
> If you want to try this as an experiment, so we can tell if this is a
> possible solution, then great. I still have hopes that we can substitute
> other parse trees and strategies within the index utilization routines,
> so how about not committing things until we've tried a few options.
>
> match_clause_to_indexkey() seems to be a starting point for what I want
> to do. Will let you know how it goes...

OK.  Check out my other posts on how op_class/pg_amop.amopopr is used to
look up if the current expression operator is a member of the
class(btree), and index opclass(oid_ops).  I could probably code
something so you could put multiple entries in pg_amop.  My issue is
that there are not that many interchangable operators to make that
useful.

Now, if you are thinking of doing some type of constant conversion
there, that may be a bigger win.  The issue is at this point in the
code, there is no guarentee the index will be used.  It is just checking
the index usability.

I think I see where you are going with this.  For queries not involving
indexes(many joins don't), it may be better to leave things for the
executor.

Also, if you can, do a fresh cvs update if you can, because the code is
a little cleaner now in that area.  Particularly, the op_class()
parameters were badly named, causing me confusion.


--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)