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Ü -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers