> > This could clearly be a KILLER APP/TYPE for us. This is a pretty
> > sophisticated use of our type system. Indexing should present no
> > problems. We supply the comparison routines and plug them in, and the
> > optimizer automatically uses the indexes.
>
> i'd like that to be true. but the section of the manual which describes
> this isn't as clear as the examples (the COMPLEX type in particular) in
> the contrib/ directory at the time i started the work. figuring out what
> OID my comparison operators happened to get and plugging these values into
> a PG_OPERATOR insert was just more than i could figure out how to automate.
Doing complex stuff like indexing with contrib stuff is tricky, and one
reason we want to move stuff out of there as it becomes popular. It is
just too hard for someone not experienced with the code to implement.
Add to this the fact that the oid at the time of contrib installation
will change every time you install it, so it is even harder/impossible
to automate.
>
> other than the OID thing i really love the postgres type system, btw, and i
> can't see why anybody would ever use MySQL (or Oracle) unless it has the
> same feature.
Yep.
--
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)
