pre-proposal: type interfaces

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: pre-proposal: type interfaces
Date: 2009-10-23 05:17:33
Message-ID: 1256275053.2580.782.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-10-23 06:55:17 Re: (WIP) VACUUM REWRITE - CLUSTER by ctid
Previous Message Peter Eisentraut 2009-10-23 05:07:16 Re: client_lc_messages