Re: Range Types and extensions - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: Range Types and extensions
Date
Msg-id AD4FC75D-DB99-48ED-9082-52EE3A4D74A6@phlo.org
Whole thread Raw
In response to Re: Range Types and extensions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Range Types and extensions
List pgsql-hackers
On Jun20, 2011, at 15:19 , Robert Haas wrote:
> On Mon, Jun 20, 2011 at 2:33 AM, Jeff Davis <pgsql@j-davis.com> wrote:
>> On Sun, 2011-06-19 at 21:29 +0200, Florian Pflug wrote:
>>> If I'm not mistaken about this, that would imply that we also cannot
>>> have two range types with the same base type, the same opclass,
>>> but different collations. Which seems rather unfortunate... In fact,
>>> if that's true, maybe restricing range types to the database collation
>>> would be best...
>> 
>> Yes, we cannot have two range types with the same base type. That is a
>> consequence of the polymorphic type system, which needs to be able to
>> determine the range type given the base type.
> 
> Boy, that's an unfortunate limitation.  :-(

Hm, I'm starting to wonder if there isn't a way around that. It seems that
this restriction comes from the desire to allow functions with the
polymorphic signature (ANYELEMENT, ANYELEMENT) -> ANYRANGE.

The only such function I can currently come up with is the generic
range constructor. Is having that worth the restriction to one
range type per base type?

Another option might be to extend polymorphic argument matching
to allow functions with the signature (<non-polymorphic args>) -> <polymorphic type>
but to require the concrete output type to be specified with a cast
at the call site. For the generic range constructor, you'd then
have to write RANGE(lower, upper)::range_type

(If we had that, we could also (finally) provide functions to
set and get fields of composite types by name. As it stands,
doing that cleanly is hard because the desired signature of
the get function, namely (record, fieldname text) -> anyelement
is not supported.)

A third approach might be to first define a PAIR type and then
define ranges on top of that. Since PAIR types wouldn't include
a comparison operators, the restriction to one PAIR type per
base type wouldn't matter. Instead of a generic RANGE constructor
you'd then use the generic PAIR constructor and cast the resulting
PAIR to whatever range you desire, i.e. write PAIR(lower, upper)::range_type.

best regards,
Florian Pflug


pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
Next
From: Florian Pflug
Date:
Subject: Re: POSIX question