Re: Implied Functional Index use

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

On Tue, 2006-07-11 at 17:31 -0400, Tom Lane wrote:
> 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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc Munro 2006-07-13 01:47:56 Re: pre_load_libraries
Previous Message Bruce Momjian 2006-07-12 22:09:31 Re: lastval exposes information that currval does not