Re: record identical operator - Review - Mailing list pgsql-hackers

Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, Sep 27, 2013 at 03:34:20PM -0700, Kevin Grittner wrote:

>> We first need to document the existing record comparison operators.
>> If they read the docs for comparing "row_constructors" and expect
>> that to be the behavior they get when they compare records, they
>> will be surprised.
>
> Well, if they appear in \do, I am thinking they should be documented.

This patch now covers the ones which are record comparison
operators, old and new.  Feel free to document the others if you
feel strongly on that point; but I don't feel that becomes the
business of this patch.

>> Because comparing primary keys doesn't tell us whether the old and
>> new values in the row all match.
>
> OK, but my question was about why we need a full set of operators rather
> than just equal, and maybe not equal.  I thought you said we needed
> others, e.g. >, so we could do merge joins, but I thought we would just
> be doing comparisons after primary keys are joined, and if that is true,
> we could just use a function.

http://www.postgresql.org/docs/current/interactive/xoper-optimization.html#AEN54334

> Actually, I am now realizing you have to use the non-binary-level equals
> comparison on keys, then the binary-level equals on rows for this to
> work --- that's pretty confusing.  Is that true?

It's a matter of replacing the = operator for record comparisons in
these two places with the new *= operator.


http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/commands/matview.c;h=238ccc72f5205ae00a15e6e17f384addfa445552;hb=master#l553

http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/commands/matview.c;h=238ccc72f5205ae00a15e6e17f384addfa445552;hb=master#l684

(With or without the new operator, the second of these needs to be
schema-qualified to avoid trouble if the user adds a different
implementation of = ahead of the pg_catalog implementation on
search_path, as users can do.)  The difference between = and *=
would not generally be visible to end users -- just to those
working on matview.c.

>> A quick query (lacking schema information and schema qualification)
>> shows what is there by default:
>
> OK, the unique list is:
>
>           opcname
>     ---------------------
>     varchar_ops
>     kd_point_ops
>     cidr_ops
>     text_pattern_ops
>     varchar_pattern_ops
>     bpchar_pattern_ops
>     (6 rows)
>
> Do these all have operators defined too?

Every operator class is associated with operators.  For example,
while text_pattern_ops uses the same = and <> operators as the
default text opclass (because that already uses memcmp), it adds
~>~, ~>=~, ~<~, and ~<=~ operators which also use memcmp (ignoring
character encoding and collation).

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company