You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PartiQL spec defines the behavior when a grouping key results in NULL and MISSING. See spec section 11.1.1:
Notice that PartiQL will group together the NULL and the MISSING grouping expressions, since any grouping
expression resulting to MISSING has been coerced into NULL before eqg does comparisons for grouping.
That would seem to imply that in the output binding tuple created by GROUP BY, NULL and MISSING would be grouped together as illustrated in example 41.
However in the case in which a group key is only MISSING, the spec could be more clear on this behavior.
E.g.
SELECT a FROM
[
{'a': 1},
{'a': 2},
{'a': MISSING}
] AS tbl
GROUP BY tbl.a AS a
Should the output binding tuple from GROUP BY be
-- case 1
<<
< a: 1 >,
< a: 2 >,
< a: NULL>
>>
or
-- case 2
<<
< a: 1 >,
< a: 2 >,
< a: MISSING>
>>
Because of the coercion that's mentioned in spec section 11.1.1, it would make more sense for case 1 to be the defined behavior (i.e. group key in binding would be NULL). Also considering the order in which the tuples are processed affecting the group key value (e.g. MISSING then NULL), case 2 would add additional implementation complexities.
After discussing with @almann, we believe that case 1 should be the spec behavior. In any case, additional spec clarification would be helpful.
The text was updated successfully, but these errors were encountered:
PartiQL spec defines the behavior when a grouping key results in
NULL
andMISSING
. See spec section 11.1.1:That would seem to imply that in the output binding tuple created by
GROUP BY
,NULL
andMISSING
would be grouped together as illustrated in example 41.However in the case in which a group key is only
MISSING
, the spec could be more clear on this behavior.E.g.
Should the output binding tuple from
GROUP BY
beor
Because of the coercion that's mentioned in spec section 11.1.1, it would make more sense for case 1 to be the defined behavior (i.e. group key in binding would be
NULL
). Also considering the order in which the tuples are processed affecting the group key value (e.g.MISSING
thenNULL
), case 2 would add additional implementation complexities.After discussing with @almann, we believe that case 1 should be the spec behavior. In any case, additional spec clarification would be helpful.
The text was updated successfully, but these errors were encountered: