Skip site navigation (1) Skip section navigation (2)

Re: extended operator classes vs. type interfaces

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Yeb Havinga <yebhavinga(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: extended operator classes vs. type interfaces
Date: 2010-04-09 14:34:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
>> 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.


In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2010-04-09 14:35:01
Subject: Re: is_absolute_path incorrect on Windows
Previous:From: Robert HaasDate: 2010-04-09 14:33:04
Subject: Re: extended operator classes vs. type interfaces

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group