Tom Lane wrote:
> Actually ... now that I re-read that remark, I think you may have done
> the wrong things with ANYENUM. I think that ANYENUM may in fact be
> closer to ANYARRAY than it is to ANYELEMENT, because ANYELEMENT pretty
> nearly means "anything at all" whereas ANYARRAY identifies a subset of
> types that share some properties, which is an accurate description of
> ANYENUM as well. In particular, it is sensible to have b-tree index
> opclasses that are declared to operate on ANYARRAY. If you've
> got b-tree support for ANYENUM, as I hope you do, then you'll have to
> patch that same spot in ri_triggers that now knows about ANYARRAY.
>
> So you might want to take another pass through the code and see if you
> shouldn't be modeling ANYENUM more closely on ANYARRAY than ANYELEMENT.
OK, thanks, I'll do that. Of course, they get used together all over the
place as well, lots ofif(typiod == ANYARRAY || typoid == ANYELEMENT) {
type of stuff in the code.
I do have b-tree (and hash) support for enums, so it sounds like I'll
have to hit the same spot. I've got what I thought was a reasonably
comprehensive test of all the enum features which passes make check, so
if there's a likely failure in that code then I'm missing a test
somewhere. Did you have a test case for the ri_triggers stuff that you
did? What's going to fail?
Thanks
Tom
