Florian Pflug <f...@phlo.org> writes: > On Jun20, 2011, at 19:16 , Merlin Moncure wrote: >> On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis <pg...@j-davis.com> wrote: >> 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?
> I suggested that previously here > http://archives.postgresql.org/pgsql-hackers/2011-06/msg00846.php > In the ensuing discussion, however, it became clear that by doing so > range types become little more than a pair of values. More specifically, > a range then *doesn't* represent a set of values, because whether or > not a value is "in" the range depends on a specific sort order. Yeah, that doesn't seem like the way to go. If a range value doesn't represent a well-defined set of base-type values, we lose a lot of the mathematical underpinnings for range operations. So ... just how awful would it be if we hard-wired range types to always use their base type's default btree sort ordering and the database's default collation? In principle that sucks, but I'm not sure how wide the use-cases actually will be for other choices. 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? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
