> What this patch does is to add two new clauses for FROM-list items, > NORMALIZE and ALIGN, which reshuffle a set of ranges into a new list > that can then be aggregated more easily. From the original message: > > > For NORMALIZE the tuples' ranges need to be split into all sub-ranges > > according to all matching ranges of the second relation. For this we > > create a subquery that first joins one relation with the range > > boundaries of the other and then sorts the result. The executor > > function splits the ranges in a sweep-line based manner. > > > > For ALIGN the tuples' ranges must be split into all intersections and > > differences with the other relation according to the join condition. > > For this we create a subquery that first joins the two relations and > > then sorts the result. The executor function splits the ranges > > accordingly in a sweep-line based manner. > > So there isn't really temporal query processing as such here, only some > helpers that can make it easier.
The goal of temporal aligners and normalizers is to split ranges to allow a reduction from temporal queries to their non-temporal counterparts. Splitting ranges is necessary for temporal query processing. Temporal aligners and normalizer may then be used as building-blocks for any temporal query construct.
> I can see how those operations can be useful, but it would help if there > were a more formal definition to be able to check that further.
We have published two papers, that contain formal definitions and related work for the temporal aligner and normalizer. Please see [1] and [2].
> What I'm missing here is some references: existing implementations, > standards, documentation, research papers, alternative ideas, rejected > alternatives, etc.
A good overview of existing implementations in DBMSs, SQL standard, and history is given in [3]. > Also, the submission is missing documentation and test cases. There are > technical terms used in the code that I don't understand.
We added a second patch with test cases and expected results. We are now writing the documentation in sgml-format. > I think there are probably many interesting applications for normalizing > or otherwise adjusting ranges. I'd like to see an overview and > consideration of other applications.
Please see the attached file adjustment.sql for some interesting applications.
> Ideally, I'd like to see these things implemented as some kind of > user-space construct, like an operator or function. I think we'd need a > clearer definition of what it is they do before we can evaluate that.
Can you please explain what you mean by "user-space construct" in this case.
