On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis <pg...@j-davis.com> wrote: > 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.
hm, what if there *was( only one range type per base type, but in the various contexts where specific ordering and collation was important you could optionally pass them in? Meaning, the specific ordering was not bound rigidly to the type, but to the operation? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
