Re: Implied Functional Index use

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Implied Functional Index use
Date: 2006-07-11 21:31:04
Message-ID: 6768.1152653464@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2006-07-11 21:43:16 Re: Three weeks left until feature freeze
Previous Message Hannu Krosing 2006-07-11 21:23:19 Re: Warm-Standby using WAL archiving / Seperate