Re: comparison operators - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: comparison operators
Date
Msg-id 53A0D9EC.30405@dunslane.net
Whole thread Raw
In response to Re: comparison operators  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: comparison operators  (Stephen Frost <sfrost@snowman.net>)
Re: comparison operators  (David G Johnston <david.g.johnston@gmail.com>)
List pgsql-hackers
On 06/17/2014 07:25 PM, Andres Freund wrote:
> On 2014-06-17 19:22:07 -0400, Tom Lane wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> I went to have a look at documenting the jsonb comparison operators, and
>>> found that the docs on comparison operators contain this:
>>>      Comparison operators are available for all relevant data types.
>>> They neglect to specify further, however. This doesn't seem very
>>> satisfactory. How is a user to know which are relevant? I know they are
>>> not available for xml and json, but are for jsonb. Just talking about
>>> "all relevant types" seems rather hand-wavy.
>> Well, there are 38 default btree opclasses in the standard system ATM.
>> Are we worried enough about this to list them all explicitly?  Given the
>> lack of complaints to date, I'm not.
>>
>> However, if we try to fudge it by saying something like "available for
>> all data types for which there is a natural linear order", I'm not
>> sure that that's 100% true; and it's certainly not complete, since
>> for instance jsonb's ordering is rather artificial, and the area-based
>> orderings of the built-in geometric types are even more so.
> It's not true for e.g. xid (which is rather annoying btw).
>


I think I'd rather just say "for many data types" or something along 
those lines, rather than imply that there is some obvious rule that 
users should be able to intuit.

For json/jsonb I think I'll just add a para saying we have them for 
jsonb and not for json.

cheers

andrew



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: btreecheck extension
Next
From: Robert Haas
Date:
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()