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