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