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