F2F2 Issue Discussions

This wiki page captures issues discussed at the F2F2, along with prevailing consensus of F2F2 attendees. We'd like to concretely resolve these as soon as possible, so we ask for feedback from WG members, particularly if you disagree with the consensus of F2F attendees.

ISSUE-11: Implicit grouping

Consensus on prohibiting projecting variables/functions on variables that are not included in the group by clause. Details are pending discussion of ISSUE-41.

ISSUE-12: HAVING vs. FILTER as keyword for limiting aggregate results

General consensus in favor of using "FILTER" as the keyword, with bglimm preferring "HAVING".

(In favor: SteveH, kasei, axel, LeeF, pgearon)

DISTINCT in aggregate functions

Consensus on allowing DISTINCT with multiple arguments to aggregate functions. DISTINCT in this case passes just the DISTINCT tuples into the aggregate function (for each group).

(In favor: SteveH, kasei, axel, LeeF, pgearon)

Star (asterisk) in aggregate functions

Consensus around only allowing asterisk as an argument to COUNT.

(In favor: SteveH, kasei, axel, LeeF, pgearon)

ISSUE-15: Syntax for custom aggregates

Mild opinion in favor of having no keyword or special syntax for custom aggregate functions (LeeF, Axel, SteveH, kasei). pgearon (and observer dajobe) expressed mild preference for a keyword to introduce custom aggregates. Consensus that this should be advice to the editors.

ISSUE-16: Mixed datatypes with built-in aggregates

Consensus that MIN/MAX should use same semantics as ORDER BY, with parts (e.g. ordering xsd:string and xsd:dateTime) being undefined/implementation defined. (SteveH, kasei, axel, LeeF, bglimm).

Consensus that SUM/AVG should use same semantics as + (SteveH, kasei, axel, LeeF, bglimm).

What happens with type errors that are projected?

Consensus that type errors that are projected should result in that solution being discarded. (SteveH, kasei, axel, LeeF, bglimm, iv_an_ru (on IRC))

Trapping type errors?

Consensus that COALESCE is a good way to trap errors. (SteveH, kasei, axel, LeeF)

Do expressions always need to be aliased to a named variable?

Mild consensus that aliases should be required. (Leef, Axel, SteveH, kasei has mild reservations)

Syntax for expressions in SELECT list

General lack of satisfaction with either:

  • Requiring commas if a projection uses at least one expression
  • Wrapping expressions and aliases with parentheses (brackets)

Sub-asks and sub-selects in FILTER

General consensus (kasei, axel, steveh, leef) to avoid the complexity of any subqueries in FILTERs.

Sub-constructs in FROM and FROM NAMED

General consensus (kasei, steveh, leef) to avoid the complexity of sub-constructs in FROM. Axel is in favor, but willing to cede the point.

ISSUE-13: Subqueries in HAVING

Consensus that this can be done as is with subqueries; no need to add here. (kasei, axel, steveh, leef)

ISSUE-39: Variable scope of alias variables

Consensus that variables on the right-hand side of "AS" (alias variables) are not in scope for the rest of the query (including projected expressions), but not including outer queries of course.

Last modified on 2 November 2009, at 23:34