Robert Haas wrote:
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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
