Re: order by, for custom types

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

In response to

Responses

Browse pgsql-hackers by date

  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(*)