From: | Tom Dunstan <pgsql(at)tomd(dot)cc> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-15 23:58:18 |
Message-ID: | 45D4F39A.4000601@tomd.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 of
if(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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-02-16 00:35:46 | Re: patch adding new regexp functions |
Previous Message | Jeremy Drake | 2007-02-15 23:15:31 | Re: patch adding new regexp functions |