Hi Leondard, Thank you for pushing this, I think the updated syntax looks really good and the semantics make sense to me.
+1 Seth On Wed, Jul 29, 2020 at 11:36 AM Leonard Xu <xbjt...@gmail.com> wrote: > Hi, Konstantin > > > > > 1) A "Versioned Temporal Table DDL on source" can only be joined on the > > PRIMARY KEY attribute, correct? > Yes, the PRIMARY KEY would be join key. > > > > > 2) Isn't it the time attribute in the ORDER BY clause of the VIEW > definition that defines > > whether a event-time or processing time temporal table join is used? > > I think event-time or processing-time temporal table join depends on fact > table’s time attribute in temporal join rather than from temporal table > side, the event-time or processing time in temporal table is just used to > split the validity period of versioned snapshot of temporal table. The > processing time attribute is not necessary for temporal table without > version, only the primary key is required, the following VIEW is also valid > for temporal table without version. > CREATE VIEW latest_rates AS > SELECT currency, LAST_VALUE(rate) -- only keep the latest > version > FROM rates > GROUP BY currency; -- inferred primary key > > > > > > 3) A "Versioned Temporal Table DDL on source" is always versioned on > > operation_time regardless of the lookup table attribute (event-time or > > processing time attribute), correct? > > > Yes, the semantics of `FOR SYSTEM_TIME AS OF o.time` is using the o.time > value to lookup the version of the temporal table. > For fact table has the processing time attribute, it means only lookup the > latest version of temporal table and we can do some optimization in > implementation like only keep the latest version. > > > Best > Leonard
