| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
| Cc: | Antonin Houska <ah(at)cybertec(dot)at>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence |
| Date: | 2019-12-24 16:08:29 |
| Message-ID: | 20191224160829.GA18317@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> @@ -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."
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexey Kondratov | 2019-12-24 17:12:32 | Physical replication slot advance is not persistent |
| Previous Message | Alvaro Herrera | 2019-12-24 15:15:20 | weird libpq GSSAPI comment |