Adjusts the EXTRACT builtin function tests to assert on the expected result in the PartiQL statement. This is to deal with the SQL specification's ambiguity related to the output type of EXTRACT. In SQL:2011 (pg 1337):
The declared type of <extract expression> is an implementation-defined exact numeric type. If <primary
datetime field> specifies SECOND, then the scale is implementation-defined; otherwise, the scale is
0 (zero).
where "exact numeric type" refers to "NUMERIC, DECIMAL, SMALLINT, INTEGER, and BIGINT" (pg 15).
Rather than defining the exact numeric type output by EXTRACT to be a decimal or integer, we add a PartiQL equality expression to assert the equivalent value.
E.g. rewrite
{
...
statement:"EXTRACT(YEAR FROM DATE '2023-04-13')",
assert:{
...
output:2023
}
},
as
{
...
statement:"EXTRACT(YEAR FROM DATE '2023-04-13') = 2023",
assert:{
...
output:true
}
},
This PR also adds some more tests that were omitted from the earlier test porting.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Related to first part of #83.
Adjusts the
EXTRACT
builtin function tests to assert on the expected result in the PartiQL statement. This is to deal with the SQL specification's ambiguity related to the output type ofEXTRACT
. In SQL:2011 (pg 1337):where "exact numeric type" refers to "NUMERIC, DECIMAL, SMALLINT, INTEGER, and BIGINT" (pg 15).
Rather than defining the exact numeric type output by
EXTRACT
to be a decimal or integer, we add a PartiQL equality expression to assert the equivalent value.E.g. rewrite
as
This PR also adds some more tests that were omitted from the earlier test porting.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.