On Wed, Aug 01, 2007 at 05:19:33AM -0000, Patrick TJ McPhee wrote: > In article <19363.1185892343@xxxxxxxxxxxxx>, > Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > % ptjm@xxxxxxxxxxxx (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 decibel@xxxxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Attachment:
pgprmxuw40N2b.pgp
Description: PGP signature
