Re: operator exclusion constraints

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: 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 04:13:17
Message-ID: 603c8f070911172013m6e930f7bnd7dba5764d60b31d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 14, 2009 at 2:27 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> New patches attached.

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.

I'm wondering if we can't use the existing
BuildIndexValueDescription() rather than the new function
tuple_as_string(). I realize there are two tuples, but maybe it makes
sense to just call it twice?

I'm attaching a revised doc patch for your consideration.

...Robert

Attachment Content-Type Size
opx-doc.patch text/x-diff 5.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2009-11-18 04:17:38 Re: Syntax for partitioning
Previous Message Itagaki Takahiro 2009-11-18 04:03:39 Re: UTF8 with BOM support in psql