Re: extended operator classes vs. type interfaces - Mailing list pgsql-hackers

Robert Haas wrote:
> On Fri, Apr 9, 2010 at 10:33 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>   
>> On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga <yebhavinga@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.
>   
Well yeah the idea was to 'automagically' have a range type available, 
if the underlying type would support it, i.e. has a lineair order and 
therefore <,>,= etc defined on it, "just like the array types", from a 
user / datatype developer perspective.
From the implementers perspective, IMHO an extra catalog entry in 
pg_type is not bad on its own, you would have one anyway if the range 
type was explicitly programmed. About different kinds of range types - I 
would not know how to 'promote' integer into anything else but just one 
kind of 'range of integer' type. So the number of extra pg_types would 
be more like O(number of linear ordered base types).

regards,
Yeb Havinga