Tom Lane wrote:
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
I still think that the most elegant solution is for stuff like collation to just
be built-in to the base types that the range is ranging over, meaning we have a
separate text base type for each text collation, and the text operators are
polymorphic over all those base types. Having collations and stuff as something
off to the side not built-in to text/etc types is the root of the problem. The
range-specific stuff can remain ANYELEMENT and no special-casing is required.
Also, besides range constructors, a generic membership test like "value in
range" is polymorphic. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
