Re: pre-proposal: type interfaces

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> For instance, one feature that I'm considering now is a "temporal join"
> which is a join on "overlaps" rather than "equals", e.g.:

> SELECT * FROM a, b WHERE a.x && b.x;

> I might try to provide a modified merge join algorithm to implement that
> more efficiently in some cases. I don't mean to discuss the feature in
> detail here (I will make a separate proposal) but the algorithm requires
> that I find the "strictly left of" operator.

Well, actually you need *two* things. The first prerequisite is to know
that the operator named && has the semantics of "overlaps" in some
generalized sense. The second prerequisite is to identify the
associated "strictly left of" operator.

As you say, we've done this in the past using operator classes. That's
worked reasonably well because what the existing code needs to know
about is equality, ordering, and hashing, and that all matches up nicely
with btree and hash opclasses.

> 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.

> 2. Invent a new system, perhaps interfaces, perhaps something else.
> 3. Use extra flags in CREATE OPERATOR somehow

The thing that would require the least amount of invention is to use the
operator class/family machinery with a new index type. Perhaps a dummy
entry in pg_am would be acceptable. (You would probably create just
operator families, with no contained classes, since the only point of a
class is to identify the minimum support set for an index and there
won't be any indexes.) An alternative is to somehow mark those GIST
opclasses that do meet the expectation about operator semantics.

regards, tom lane