Re: Range Types and extensions

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Darren Duncan <darren(at)darrenduncan(dot)net>
Subject: Re: Range Types and extensions
Date: 2011-06-20 14:01:00
Message-ID: AD4FC75D-DB99-48ED-9082-52EE3A4D74A6@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jun20, 2011, at 15:19 , Robert Haas wrote:
> On Mon, Jun 20, 2011 at 2:33 AM, Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2011-06-20 14:16:58 Re: POSIX question
Previous Message Michael Meskes 2011-06-20 13:54:36 Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.