2017-02-22 19:43 GMT+01:00 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>:
> On 2/16/17 07:41, Robert Haas wrote:
>> Also, it sounds like all of this is intended to work with ranges that
>> are stored in different columns rather than with PostgreSQL's built-in
>> range types.
>
> Yeah, that should certainly be changed.
Our syntax supports PostgreSQL's built-in range types and ranges that
are stored in different columns.
For instance, for range types an ALIGN query would look like this: SELECT * FROM (r ALIGN s ON q WITH (r.t, s.t)) c
... and for ranges in different columns like this: SELECT * FROM (r ALIGN s ON q WITH (r.ts, r.te, s.ts, s.te)) c
... where r and s are input relations, q can be any join qualifier, and r.t, s.t, r.ts, r.te, s.ts, and s.te can be
anycolumn name. The latter represent the valid time intervals, that is time point start, and time point end of each
tuplefor each input relation. These can be defined as four scalars, or two half-open, i.e., [), range typed
values.
It would reduce the size of our patch and simplify the overall structure,
if we would remove the possibility to express valid time start points and end
points in different columns.
Do you think it is better to remove the syntax for ranges expressed in
different columns?
However, internally we still need to split the
range types into two separate points, because NORMALIZE does not make a
distinction between start and end timepoints while grouping, therefore we
have only one timepoint attribute there (i.e., P1), which is the union of
start and end timepoints (see executor/nodeTemporalAdjustment.c). A second
constraint is, that we support currently only half-open intervals, that is,
any interval definition (open/closed/half-open) different from the PostgreSQL's
default, i.e., [), leads to undefined results.
Best regards,
Anton, Johann, Michael, Peter