From: | Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: order by, for custom types |
Date: | 2005-11-19 01:24:25 |
Message-ID: | 9A435649-40A3-494A-A1B0-C2A3D6B0FB76@pointblue.com.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2005-11-18, at 22:53, Tom Lane wrote:
> Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> writes:
>> I have all operators required for b-tree, gist up here, and gist
>> index defined. But still "order by custom_type" won't work.
>
> Define "won't work" ... what happens?
>
Wildcards cause things not to work as they should
consider everything in [] brackets to be a possible choice and those
three:
a = 1.2.3.4
b = 1.[2,3].3.4
c = 1.3.3.4
a = b, b = c, but a <> c, I was told that because of that btree won't
work on my type. (on irc, that was AndrewSN as I recall).
> You don't need an index, but a b-tree operator class is a good idea.
> Still, it should be possible to sort with only a "<" operator --- at
> the moment anyway. (I've been thinking about some ideas that would
> effectively require a b-tree opclass to do sorting, so this might not
> still be true in 8.2 ...)
I do have all operators required for btree, no operator class
defined, every single operator. Btree requires some function apart
from operators, this one is not defined, but I do have = operator as
well.
--
GJ
"If we knew what we were doing, it wouldn't be called Research, would
it?" - AE
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-11-19 01:56:13 | Re: Some array semantics issues |
Previous Message | Josh Berkus | 2005-11-19 01:22:34 | Re: Improving count(*) |