Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence

24.12.2019 19:08, Alvaro Herrera wrote:
>> @@ -106,6 +106,18 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
>>       </listitem>
>>      </varlistentry>
>>   
>> +    <varlistentry>
>> +    <term><literal>NOT BITWISE</literal></term>
>> +    <listitem>
>> +     <para>
>> +      If present, the operator class equality is not the same as equivalence.
>> +      For example, two numerics can compare equal but have different scales.
>> +      Most opclasses implement bitwise equal comparison, alternative behaviour
>> +      must be set explicitly.
>> +     </para>
>> +    </listitem>
>> +   </varlistentry>
> Am I the only one bothered by the fact that this patch (and all
> downstream discussion) reduces the term "bitwise equality" to simply
> "bitwise"?  It reads really strange to me, both in the resulting SQL
> grammar as well as in struct names, code comments etc.  "This operator
> class is bitwise."
>
Thank you for pointing that out.
Do you have any suggestions on how to name it better?
Should it rather be "CREATE OPERATOR CLASS ... BITWISE EQUAL" ?

In the recent version of the patch I also had a question,
if it will be useful to do this option enum instead of boolean:

> We can make this 'opcisbitwise' parameter enum (or char) instead of 
> boolean to mark
> "always bitwise", "never bitwise" and "maybe bitwise". 

This decision will also affect the syntax. So I'd rather agree on that 
before updating syntax.
Do you have an opinion on that?

-- 
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company