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

From Simon Riggs
Subject Re: Implied Functional Index use
Date
Msg-id 1152742281.2654.74.camel@localhost.localdomain
Whole thread Raw
In response to Re: Implied Functional Index use  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Implied Functional Index use  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Implied Functional Index use  ("Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at>)
List pgsql-hackers
On Tue, 2006-07-11 at 17:31 -0400, Tom Lane wrote:
> 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.

Normally, I would not suggest that we do things only for certain data
types only. In this case however, it seems that the reason it would work
only for INTEGER and TEXT data types is that they are simple atomic
datatypes that have the required properties. So doing this for those
datatypes only seems permissable on a theoretical basis, rather than
just because we can't be bothered to do it for more complex types.

--  Simon Riggs EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Online index builds
Next
From: Bruce Momjian
Date:
Subject: Re: lastval exposes information that currval does not