Re: Implied Functional Index use - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Implied Functional Index use
Date
Msg-id 6768.1152653464@sss.pgh.pa.us
Whole thread Raw
In response to Implied Functional Index use  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Implied Functional Index use  (Peter Eisentraut <peter_e@gmx.net>)
Re: Implied Functional Index use  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> ...
> - add a new boolean to pg_operator to allow us to define which operators
> offer true equality
> ...

This would be useful for other purposes too, as we keep coming up
against "what's the equality operator for this datatype" problems.
However, the restriction to "true" equality, such that we can assume
x = y implies f(x) = f(y) for every immutable function f on the datatype
(note this need not necessarily mean bitwise equality --- it depends on
what operations the datatype provides), seems like a problem.  For
instance, the ordinary = operators on float and numeric are NOT true
equality, nor do we provide any true equality in this sense for these
common datatypes.  We could hardly get away with using this concept
to drive foreign-key comparisons, if it doesn't work for float or
numeric.

We could invent some more-complex concept involving "well, this is
equality, but there are some functions for which f(x) might differ
from f(y) anyway" and then mark the presumably-few functions that
could produce divergent results --- examples are sgn() for float8
and anything dependent on dscale for numeric.  This seems ugly and
error prone however.

Anyone have a better idea?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: Three weeks left until feature freeze
Next
From: Robert Treat
Date:
Subject: Re: More nuclear options