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 20:36:50
Message-ID: x2r603c8f071004091336ud8439662mcfffeaba8c423f2@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Apr 9, 2010 at 4:01 PM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
> Robert Haas wrote:
>>
>> On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
>>
>>>
>>> .. I now see the example of different ranges in your original mail with
>>> different unit increments. Making that more general so there could be
>>> continuous and discrete ranges and for the latter, what would the
>>> increment
>>> be.. OTOH is a range of integers with increment x a different type from
>>> range of integers with increment y, if x<>y? Maybe the increment step and
>>> continuous/discrete could be typmods.
>>>
>>
>> Nope, not enough bits available there.  This is fundamentally why the
>> typid/typmod system is so broken - representing a type as a fixed size
>> object is extremely limiting.  A fixed size object that MUST consist
>> of a 32-bit unsigned OID and a 32-bit signed integer is even more
>> limiting.  Fortunately, we don't need to solve that problem in order
>> to implement range types: we can just have people explicitly create
>> the ones they need.  This will, for example, avoid creating ranges
>> over every composite type that springs into existence because a table
>> is created, even though in most cases a fairly well-defined range type
>> could be constructed.
>>
>
> Ok, no typmod, not default extra types for base types, but the concept of an
> still there is one aspect of ranges (may I say intervals?) of 'things' is
> something generic, and code to handle intervals of things could be shared
> between datatype implementations. A way to have generic support without
> automatic new types could be with something that looks like:
>
> What about
> CREATE TYPE ivl_int AS INTERVAL OF integer;
>
> SELECT '[1;2]'::ivl_int;
> etc

Yeah, that's how it has to work, I think.

...Robert

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2010-04-09 20:37:38
Subject: Re: Gsoc XQuery
Previous:From: pavelbarosDate: 2010-04-09 20:36:04
Subject: GSoC - proposal - Materialized Views in PostgreSQL

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