Re: "anyelement2" pseudotype

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