Re: extended operator classes vs. type interfaces

On Fri, Apr 9, 2010 at 10:33 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga <yebhavinga(at)gmail(dot)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