Re: record identical operator

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Ü