Andrew Dunstan wrote
> On 06/17/2014 07:25 PM, Andres Freund wrote:
>> On 2014-06-17 19:22:07 -0400, Tom Lane wrote:
>>> Andrew Dunstan <
> andrew@
> > 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.
>
> 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.
Ideal world for me: we'd list the data types that do not provide comparison
operators (or not a full set) by default with links to the section in the
documentation where the reasoning for said omission is explained and/or
affirmed.
My other reaction is that referring to data types at all in this section is
unnecessary - other than maybe to state (which it does not currently) that
both sides of the comparison must be of the same (or binary equivalent, like
text/varchar) type or there must exist an implicit cast for one of the
operands. Much of that knowledge is implied and well understood though, as
is the fact that operators are closely associated with data types. IOW - I
would be fine with removing "Comparison operators are available for all
relevant data types" and not replacing it with anything. Though "for many
data types" is my preferred equivalent phrase for the same reasons Andrew
noted.
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/comparison-operators-tp5807654p5807757.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
