On Jun20, 2011, at 15:19 , Robert Haas wrote: > On Mon, Jun 20, 2011 at 2:33 AM, Jeff Davis <pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
