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