Re: order by, for custom types

From: Andrew - Supernews <andrew+nonews(at)supernews(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: order by, for custom types
Date: 2005-11-20 06:54:14
Message-ID: slrndo07cm.nb4.andrew+nonews@trinity.supernews.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2005-11-19, Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> wrote:
> 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).

Probably. But nothing stops you defining equality and ordering operators
that _do_ work for btree, and hence sorting, it's just that those operators
won't be any use for the matching semantics.

It's clear that for your data type that there is a concept of "equality"
in which all three of your values a,b,c above are unequal. My advice would
be (and I'm sure I suggested this at the time) that you reserve the '='
operator for a true equality operation, and use some other operator such as
~ or @ for the "matches" semantics that you want for your application.
Having an intransitive '=' operator violates the POLA, even if it doesn't
actively break anything otherwise (I have no idea if it does).

> 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.

You still don't seem to understand that what btree requires is not an
operator _called_ '=', but an operator with the logical semantics of
"equality". That operator can be called anything you please (it doesn't
have to have the name '=').

Sorting doesn't need an equality operator, since it can fabricate one if
given a suitable < operator, i.e. one that constitutes a strict weak
ordering over the elements to be sorted; it can rely on the fact that
NOT(a < b) AND NOT(b < a) implies that a and b are equivalent for sorting
purposes. (The requirement that < constitute a strict weak ordering is
enough to ensure that this is an equivalence relation, and therefore
transitive; if < does not meet this requirement then sorting may give wrong
answers, loop forever, or possibly crash.)

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2005-11-20 07:43:05 Re: Returning multiple result sets
Previous Message Alvaro Herrera 2005-11-19 23:02:08 Re: Returning multiple result sets