Re: "anyelement2" pseudotype

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tom Dunstan <pgsql(at)tomd(dot)cc>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Matt Miller <pgsql(at)mattmillersf(dot)fastmail(dot)fm>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "anyelement2" pseudotype
Date: 2007-02-14 19:51:53
Message-ID: 4564.1171482713@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Tom Dunstan <pgsql(at)tomd(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-02-14 20:00:53 Re: Plan for compressed varlena headers
Previous Message mark 2007-02-14 19:21:38 Re: HOT WIP Patch - version 1