Re: "anyelement2" pseudotype - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "anyelement2" pseudotype
Date
Msg-id 4564.1171482713@sss.pgh.pa.us
Whole thread Raw
In response to Re: "anyelement2" pseudotype  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "anyelement2" pseudotype  (Tom Dunstan <pgsql@tomd.cc>)
List pgsql-hackers
I wrote:
> Tom Dunstan <pgsql@tomd.cc> writes:
>> Regarding the type system understanding ANYENUM, most of the type system 
>> treats ANYENUM identically to ANYELEMENT, the only parts that really 
>> need to understand it are the bits that try to tie down concrete types. 

> The reason I'm feeling annoyed with ANYfoo stuff today is that yesterday
> I had to put a special hack for ANYARRAY into the ri_triggers code,
> which you'd think would have no concern with it.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: mark@mark.mielke.cc
Date:
Subject: Re: HOT WIP Patch - version 1
Next
From: Tom Lane
Date:
Subject: Re: Plan for compressed varlena headers