| 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-15 19:34:40 |
| Message-ID: | 29364.1171568080@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Dunstan <pgsql(at)tomd(dot)cc> writes:
> 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?
ri_HashCompareOp, which I think is mainly invoked in cases of UPDATEing
a PK or FK row (to see whether the relevant columns changed). If one
of the columns is an enum type, it's going to need to be able to realize
that coercing that to ANYENUM is a no-op.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-02-15 19:46:44 | Re: "anyelement2" pseudotype |
| Previous Message | Merlin Moncure | 2007-02-15 18:44:10 | Re: Fixing insecure security definer functions |