Re: Comparing arrays of composite types - Mailing list pgsql-general

From Alban Hertroys
Subject Re: Comparing arrays of composite types
Date
Msg-id 58DD67BB-2E1D-4AAB-96CC-68649D4134A1@solfertje.student.utwente.nl
Whole thread Raw
In response to Re: Comparing arrays of composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On 21 Aug 2009, at 22:12, Tom Lane wrote:

> Alban Hertroys <dalroi@solfertje.student.utwente.nl> writes:
>> I have created operators on unit_token for =, <, <=, > and >=, but
>> either I did something wrong defining my operators or the error is
>> pointing to some other problem.
>
> The mere fact that the operator is named '=' means nothing to
> Postgres.
> You need to create an operator class or family that shows the operator
> is equality in a btree opclass.  Array comparison looks for the
> default
> btree opclass for the element data type to decide what to do.


I see, that's the kind of answer I was looking for, thanks.

I didn't see any mention to this effect in the places I looked at in
the fine manual (mostly type creation and operator related stuff),
maybe there's some room for improvement there?

No longer needed for 8.4 probably, but many people don't install .0-
releases so I expect 8.3 will be commonly in use for a while yet
(which is also the reason I'd prefer my unit conversion database to
work in 8.3).

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.


!DSPAM:737,4a8f1e7610131363520008!



pgsql-general by date:

Previous
From: Nathan Jahnke
Date:
Subject: bytea corruption?
Next
From: Arturo Pérez
Date:
Subject: Re: Problem with bacula and 8.3/8.4