Re: operator exclusion constraints

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: operator exclusion constraints
Date: 2009-11-18 14:14:24
Message-ID: 87iqd7c43j.fsf@hi-media-techno.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Forgive me if this is discussed before, but why does this store the
> strategy numbers of the relevant operators instead of the operators
> themselves? It seems like this could lead to surprising behavior if
> the user modifies the definition of the operator class.

Wild guess:

http://www.postgresql.org/docs/8.4/static/xindex.html

34.14.2. Index Method Strategies

The operators associated with an operator class are identified by
"strategy numbers", which serve to identify the semantics of each
operator within the context of its operator class. For example,
B-trees impose a strict ordering on keys, lesser to greater, and so
operators like "less than" and "greater than or equal to" are
interesting with respect to a B-tree. Because PostgreSQL allows the
user to define operators, PostgreSQL cannot look at the name of an
operator (e.g., < or >=) and tell what kind of comparison it
is. Instead, the index method defines a set of "strategies", which can
be thought of as generalized operators. Each operator class specifies
which actual operator corresponds to each strategy for a particular
data type and interpretation of the index semantics.

Regards,
--
dim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2009-11-18 14:21:43 Re: operator exclusion constraints
Previous Message Peter Eisentraut 2009-11-18 14:06:03 Re: UTF8 with BOM support in psql