I've submitted a patch to pgsql-patches to fix the following
limitations on type bool:
test=> create table foo(b bool);
CREATE
test=> create index foo_idx on foo(b);
ERROR: Can't find a default operator class for type 16.
test=> select * from foo where b<=b;
ERROR: Unable to identify an operator '<=' for types 'bool' and 'bool' You will have to retype this query using
anexplicit cast
test=> select * from foo where b>=b;
ERROR: Unable to identify an operator '>=' for types 'bool' and 'bool' You will have to retype this query using
anexplicit cast
test=>
The oversite that leads to one not being able to define an index on
type bool I can understand, but who the heck would bother to go to
all the trouble of adding type "bool" and only define four of the
six standard comparison operators?
Oh well...
Tom suggested I submit the patch to pgsql-patches, and I ran my OID
assignments for the new procs, bool_ops, etc past Thomas at Tom's
suggestion, the regression tests pass, I've done some additional testing,
etc.
I didn't look into adding bool to the hash ops defined in pg_amop,
after all yesterday afternoon was the first I'd looked into adding
something to the catalog code and the getting the above set of
functions in took me four hours of reading docs and code, testing
making the diff, etc.
I assume not having a type added to hash ops isn't fatal, because
"numeric" isn't there and Jan strikes me as being a very thorough
guy...
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.