From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Types and extensions |
Date: | 2011-06-07 15:15:38 |
Message-ID: | 13756.1307459738@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Mon, Jun 6, 2011 at 6:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> By my count there are only about 20 datatypes in core for which it looks
>> sensible to provide a range type (ie, it's a non-deprecated,
>> non-composite type with a standard default btree opclass). For that
>> many, we might as well just build 'em in.
> right. hm -- can you have multiple range type definitions for a
> particular type?
In principle, sure, if the type has multiple useful sort orderings.
I don't immediately see any core types for which we'd bother. (In
particular I don't see a use case for range types corresponding to
the *_pattern_ops btree opclasses, especially now that COLLATE "C"
has rendered them sorta obsolete.)
BTW, Jeff, have you worked out the implications of collations for
textual range types? I confess to not having paid much attention
to range types lately.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-06-07 15:29:10 | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |
Previous Message | Tom Lane | 2011-06-07 15:11:16 | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |