On Wed, Aug 01, 2007 at 05:19:33AM -0000, Patrick TJ McPhee wrote: > In article <[EMAIL PROTECTED]>, > Tom Lane <[EMAIL PROTECTED]> wrote: > % [EMAIL PROTECTED] (Patrick TJ McPhee) writes: > % > One problem with this idea is the treatment of implicit casts between > % > numeric types in TypeCategory(). For implicit casts to work, the type's > % > OID has to be listed in that function (i.e., it has to be a built-in > type). > % > % That's not the case. There probably are some things that won't work > % nicely if TypeCategory() doesn't recognize the type as numeric category, > % but to claim that implicit casts won't work at all is wrong. > > I didn't say they won't work at all, but I do say that they won't work > completely. I had to play around with it before I remembered where things > broke down. Suppose you have a type called unsigned, written in C, with an > implicit cast from int4 to unsigned. Then > > SELECT 23::unsigned > UNION > SELECT 0; > > will work if unsigned has one of the numeric OIDs known to TypeCategory(), > but not if it was defined normally using CREATE TYPE. > > You can characterise this as working, just not nicely, but it's still > a problem for anyone trying to implement unsigned, or any other kind of > numeric value, as a user-defined type.
Be that as it may, I suspect that if someone puts forward a working set of uint2/4/8 it'd be considered for inclusion. -- Decibel!, aka Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
pgpsQsPEhDfKG.pgp
Description: PGP signature