On Mon, 2011-06-20 at 16:01 +0200, Florian Pflug wrote:
> 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?
Good point.
Having constructors is obviously important, but perhaps they don't have
to be generic. We could generate catalog entries for each constructor
for each range type, and name them after the range type itself. So,
instead of: range(1, 10)
you'd write: int4range(1,10)
That actually might be better anyway, because relying on the polymorphic
version is not perfect now anyway. For instance, if you want an
int8range using the generic range() constructor, you need a cast.
We'd still need to get the polymorphic type system to work the way we
want in this case. I'll look into that.
> 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
Interesting idea.
> 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.
Another interesting idea. A little awkward though, and doesn't offer
much opportunity to specify inclusivity/exclusivity of the bounds.
Regards,Jeff Davis