Re: record identical operator - Mailing list pgsql-hackers

Dimitri Fontaine <dimitri@2ndQuadrant.fr> wrote:
> Kevin Grittner <kgrittn@ymail.com> writes:
>> change, but if '1.4' was stored in a column copied into a matview
>> and they later updated the source to '1.40' the increase in
>> accuracy would not flow to the matview.  That would be a bug, not a
>> feature.
>
> Maybe the answer to that use case is to use the seg extension?
>
>   http://www.postgresql.org/docs/9.3/interactive/seg.html

You are arguing that we should provide lesser support for numeric
columns (and who knows how many other types) in materialized views
than we do in streaming replication, pg_dump,
suppress_redundant_updates_trigger(), and other places?  Why?

> IOW, colour me unconvinced about that binary-equality opclass use case
> in MatViews. We are trusting the btree equality operator about
> everywhere in PostgreSQL and it's quite disturbing to be told that in
> fact we should not trust it.

Who said we should not trust it?  I have said that equality in
PostgreSQL does not mean the two values appear the same or behave
the same in all cases -- the definer of the class gets to determine
how many definitions of equality there are, and which (if any) is
tied to the = operator name.  That should not be news to anybody;
it's in the documentation.  I'm proposing a second definition of
equality with a different operator name for comparing two records,
without in any way disturbing the existing definition.  I am taken
completely by surprise that in this case creating a second opclass
for something is somehow controversial.  The documentation I cited
previously provides a clear example of another case where two
completely different concepts of equality for a type are useful.

We have, as a community, gone to a fair amount of trouble  to make
the concept of equality pluggable and allow multiple types of
equality per type.  To me it seems the perfect tool to solve this
problem.  Why the fuss?

> Would it make sense for you to produce a patch without the extra
> operators, behavior, opclass and opfamily here so that we can focus on
> the MatView parts of it?

No, matviews cannot be fixed without the new operators.  Here are
the stats on the patch:

kgrittn@Kevin-Desktop:~/pg/master$ git diff --stat master..matview
 contrib/citext/expected/citext.out       |   41 +++
 contrib/citext/expected/citext_1.out     |   41 +++
 contrib/citext/sql/citext.sql            |   23 ++
 src/backend/commands/matview.c           |    7 +-
 src/backend/utils/adt/rowtypes.c         |  482 ++++++++++++++++++++++++++
 src/include/catalog/pg_amop.h            |   10 +
 src/include/catalog/pg_amproc.h          |    1 +
 src/include/catalog/pg_opclass.h         |    1 +
 src/include/catalog/pg_operator.h        |   14 +
 src/include/catalog/pg_opfamily.h        |    1 +
 src/include/catalog/pg_proc.h            |   12 +-
 src/include/utils/builtins.h             |    7 +
 src/test/regress/expected/opr_sanity.out |    7 +-
 13 files changed, 642 insertions(+), 5 deletions(-)

The changes to matview.c are the only ones that are
matview-specific.  Basically, that consists of using the new
operator instead of = in a couple places.

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