pre-proposal: type interfaces - Mailing list pgsql-hackers

From Jeff Davis
Subject pre-proposal: type interfaces
Date
Msg-id 1256275053.2580.782.camel@jdavis
Whole thread Raw
Responses Re: pre-proposal: type interfaces
List pgsql-hackers
I am starting to plan a few features that are important for temporal
data, and one prerequisite for several of them is the ability to find an
operator that fills a certain role.

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. 

So, after I recognize that a temporal join is required, I need to be
able to identify the << operator. But how? In other languages, it would
probably be done with something like an "interface", but we don't have
that concept here. The internals generally use operators attached to the
default btree opclass, but I don't think that works very well here.

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.2. Invent a new system, perhaps interfaces, perhaps something else.3. Use extra flags in CREATE OPERATOR
somehow

Thoughts?

Regards,Jeff Davis





pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: client_lc_messages
Next
From: "Joshua D. Drake"
Date:
Subject: Re: per table random-page-cost?