On 09/18/2013 05:54 PM, Kevin Grittner wrote:
> ...
> I think the hardest part will be documenting the difference between
> the row value constructor semantics (which are all that is
> currently documented) and the record equality semantics (used for
> sorting and building indexes). In a green field I think I would
> have argued for having just the standard semantics we have
> documented, and modifying our sort execution nodes and index builds
> to deal with that. This is one of those cases where the breakage
> from changing to that is hard to justify on a cleaner conceptual
> semantics basis.
>
> There also seems to be universal agreement that the operator names
> should be something other than what I put in the v1 patch, but we
> don't have agreement on what should be used instead. We need six
> operators, to support the btree am requirements. Currently the
> patch has:
>
> === !== >== >>> <== <<<
>
> Suggested "same as" operators so far are:
>
> ====
> =====
> <<=>>
> =><=
>
> Anyone want to champion one of those, or something else? How about
> the other five operators to go with your favorite?
ANother take would be using "possibly unequal" for this with operator
defined as
*==* (*definitely* equal , or guaranteed to be equal)
the inequality operator would thus become !== (may be not equal)
and ordering ops would be ?<==(maybe smaller or equal), ?<(maybe smaller)
and same for larger ?>== and ?>
as a table
*==* "binary equal, surely very equal by any other definition as wall"
!==? "maybe not equal" -- "binary inequal, may still be equal by
other comparison methods"
<==? "binary smaller or equal, may be anything by other comparison
methods"
<?
>==?
>?
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ