Re: comparison operators

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: comparison operators
Date: 2014-06-18 00:14:36
Message-ID: 53A0D9EC.30405@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-06-18 00:18:37 Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Previous Message Robert Haas 2014-06-18 00:11:38 Re: btreecheck extension