| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(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 14:00:09 |
| Message-ID: | 1258552809.19351.25.camel@jdavis-laptop |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I'm in Tokyo right now, so please excuse my abbreviated reply.
On Tue, 2009-11-17 at 23:13 -0500, Robert Haas wrote:
> Forgive me if this is discussed before, but why does this store the
> strategy numbers of the relevant operators instead of the operators
> themselves?
At constraint definition time, I need to make sure that the strategy
numbers can be identified anyway, so it wouldn't save any work in
ATAddOperatorExclusionConstraint. At the time it seemed slightly more
direct to use strategy numbers in index_check_constraint, but it's
probably about the same.
> It seems like this could lead to surprising behavior if
> the user modifies the definition of the operator class.
Right now, operator classes can't be modified in any meaningful way. Am
I missing something?
> 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?
Are you suggesting I change the error output, or reorganize the code to
try to reuse BuildIndexValueDescription, or both?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2009-11-18 14:06:03 | Re: UTF8 with BOM support in psql |
| Previous Message | Andrew Dunstan | 2009-11-18 13:52:20 | Re: UTF8 with BOM support in psql |