On Fri, Apr 9, 2010 at 10:33 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga <yebhavi...@gmail.com> wrote: >> Robert Haas wrote: >>> >>> Under the first type [4pm,5pm) = >>> [4pm,4:59:59pm], while under the second [4pm,5pm) = [4pm,4:59pm]. >>> >>> Thoughts? >>> >> >> The examples with units look a lot like the IVL<PQ> datatype from HL7, see >> http://www.hl7.org/v3ballot/html/infrastructure/datatypes_r2/datatypes_r2.htm >> >> About a type interface, the HL7 spec talks about promotion from e.g. a >> timestamp to an interval (hl7 speak for range) of timestamps (a range), and >> demotion for the back direction. Every 'quantity type', which is any type >> with a (possibly partially) lineair ordered domain, can be promoted to an >> interval of that type. In PostgreSQL terms, this could perhaps mean that by >> 'tagging' a datatype as a lineair order, it could automatically have a range >> type defined on it, like done for the array types currently. > > The way we've handled array types is, quite frankly, horrible. It's > bad enough that we now have two catalog entries in pg_type for each > base type; what's even worse is that if we actually wanted to enforce > things like the number of array dimensions we'd need even more - say, > seven per base type, one for the base type itself, one for a > one-dimensional array, one for a two-dimensional array, one for a > three-dimensional array. And then if we want to support range types > that's another one for every base type, maybe more if there's more > than one kind of range over a base type. It's just not feasible to > handle derived types in a way that require a new instance of each base > type to be created for each kind of derived type. It scales as > O(number of base types * number of kinds of derived type), and that > rapidly gets completely out of hand
...which by the way, doesn't mean that your idea is bad (although it might not be what I would choose to do), just that I don't think our current infrastructure can support it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
