2017-02-22 19:43 GMT+01:00 Peter Eisentraut <peter.eisentr...@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 any column name. The latter represent the valid time intervals, that is time point start, and time point end of each tuple for 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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers