On Mon, 2011-06-20 at 13:43 -0400, Tom Lane wrote: > The other viable alternative seems to be to require those two properties > (btree opclass and collation) to be part of a specific range type > definition. The complaint about that seemed to be that we couldn't > infer an ANYRANGE type given only ANYELEMENT, but could we alleviate > that by identifying one range type as the default for the base type, > and then using that one in cases where we have no ANYRANGE input?
Yes, that sounds similar to Florian's suggestion, and I think there may be a solution down this path. However, if we're going to have range types with non-default orderings, then we need a way to construct them. I suggested that, if constructors are the primary problem case, then just generate non-polymorphic constructors at range type definition time, named after the range type name. I'll look into that approach. 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