From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
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 19:16:06 |
Message-ID: | 25418.1256325366@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> 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.
Well, the problem with that is that GIST strategy numbers are
historically an internal implementation detail for any particular
opclass, and so trying to standardize them now is going to mean lots
of incompatibility with third-party opclasses.
I'd feel more comfortable with being able to add some flags to an
opclass (or more likely an opfamily) that assert that its strategy
numbers agree with some convention or other. Maybe a bitmap so
that there's room for multiple future conventions of this kind?
For instance it's certainly conceivable that a GIST class could
support both btree-compatible and overlaps operators.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | João Eugenio Marynowski | 2009-10-23 19:26:38 | Re: table corrupted |
Previous Message | Greg Stark | 2009-10-23 17:16:34 | Re: pre-proposal: type interfaces |