From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pre-proposal: type interfaces |
Date: | 2009-10-23 17:16:34 |
Message-ID: | 407d949e0910231016k2d11cf6ai54fa304f7bc25515@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 23, 2009 at 7:34 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The way I see it, we have two approaches:
>> 1. Try to make the current system work by standardizing the strategy
>> numbers for GiST somehow, and then use the default GiST operator class,
>> if available.
>
> This proposal is a non-starter, because one of the whole points of GIST
> is that it can support multiple sets of semantics. There is no reason
> at all to assume that every GIST opclass must include operators having
> the semantics of overlaps and to-left-of.
I always thought it was strange that the GIST strategy numbers were
completely meaningless. It does seem like assigning meaning to
strategy numbers gradually as we learn new interrelated indexable
strategies. We would still have a range of values for new non-standard
semantics, but at least the common ones would be nailed down.
I'm not sure that solves the problem because the "default" gist
operator class isn't necessarily going to be the one with the
strategies this needs, though I suppose normally people would want to
make the default operator class for each data type one which supports
the most strategies.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-10-23 19:16:06 | Re: pre-proposal: type interfaces |
Previous Message | Magnus Hagander | 2009-10-23 16:52:47 | Re: client_lc_messages |