In SQL, T1 JOIN T2 USING (a,b,c) is equivalent to an equijoin of T1 and T2 on conditions that equate the a column from T1 to the a column from T2, and the same for b and c.
T1 NATURAL JOIN T2 is, essentially, USING(...) on all the columns that are the same in T1 and T2.
Importantly, T1 and T2 here are not necessarily direct table references -- they themselves can be complex join expressions. Consequently, the definition of what these operators do to data requires static knowledge of the "columns" present in T1 and T2. This is available in SQL but not, currently, in PartiQL.
Furthermore, while it would be possible to define USING(...) in PartiQL when static typing becomes available, there appears to be no way to define an untyped variant of this operator that would support this maxim from the PartiLQ charter: “The results of a query do not change as schema is added or changed, as long as the data itself is the same.” This construct may have to be introduced as one without an untyped counterpart, probably forcing us to modify the preceding maxim somewhat.
In SQL,
T1 JOIN T2 USING (a,b,c)
is equivalent to an equijoin ofT1
andT2
on conditions that equate thea
column fromT1
to thea
column fromT2
, and the same forb
andc
.T1 NATURAL JOIN T2
is, essentially,USING(...)
on all the columns that are the same inT1
andT2
. Importantly,T1
andT2
here are not necessarily direct table references -- they themselves can be complex join expressions. Consequently, the definition of what these operators do to data requires static knowledge of the "columns" present inT1
andT2
. This is available in SQL but not, currently, in PartiQL.Furthermore, while it would be possible to define
USING(...)
in PartiQL when static typing becomes available, there appears to be no way to define an untyped variant of this operator that would support this maxim from the PartiLQ charter: “The results of a query do not change as schema is added or changed, as long as the data itself is the same.” This construct may have to be introduced as one without an untyped counterpart, probably forcing us to modify the preceding maxim somewhat.This depends on partiql/partiql-lang#21.