You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@asterixdb.apache.org by mb...@apache.org on 2021/03/06 16:57:56 UTC
[asterixdb] 09/17: [NO ISSUE][DOC] Facilitate content reuse
This is an automated email from the ASF dual-hosted git repository.
mblow pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/asterixdb.git
commit 2ee9720eaeac9555800f02fa872d64ac48c4082d
Author: Simon Dew <Si...@couchbase.com>
AuthorDate: Wed Mar 3 15:30:54 2021 +0000
[NO ISSUE][DOC] Facilitate content reuse
- Fix formatting of syntax diagram titles
- Fix line spacing, get rid of horizontal rules
- Fix paragraph indents
- Ensure unique anchor IDs
- Move query intro from query title to query document
- Move SQL++ book link to intro
- Standardize Example headings
- Standardize tabs to spaces and add numeric callouts
- Rewrite paragraphs to avoid markup errors
- Fix links
- Fix admonitions
- Fix punctuation and spelling errors
- Fix entity markup
- Add extra line space at EOF after indented text
- Other miscellaneous fixes
Change-Id: If8e995d9085e85160bbdc02b1d28c331a683f5c4
Reviewed-on: https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/10305
Integration-Tests: Jenkins <je...@fulliautomatix.ics.uci.edu>
Tested-by: Jenkins <je...@fulliautomatix.ics.uci.edu>
Reviewed-by: Dmitry Lychagin <dm...@couchbase.com>
---
.../src/main/markdown/builtins/14_window.md | 22 +-
.../src/main/markdown/builtins/15_bitwise.md | 1 +
.../src/main/markdown/builtins/9_aggregate_sql.md | 4 +-
.../main/markdown/datamodel/datamodel_composite.md | 1 +
.../datamodel/datamodel_primitive_common.md | 2 +-
.../asterix-doc/src/main/markdown/sqlpp/1_intro.md | 3 +-
.../asterix-doc/src/main/markdown/sqlpp/2_expr.md | 289 +++++-------
.../asterix-doc/src/main/markdown/sqlpp/3_query.md | 515 +++++++++------------
.../src/main/markdown/sqlpp/3_query_title.md | 20 -
.../src/main/markdown/sqlpp/4_windowfunctions.md | 136 ++----
.../src/main/markdown/sqlpp/7_ddl_dml.md | 384 +++++++--------
.../src/main/markdown/sqlpp/7_ddl_head.md | 12 +-
.../main/markdown/sqlpp/appendix_2_parameters.md | 7 +-
.../main/markdown/sqlpp/appendix_3_resolution.md | 10 +-
.../main/markdown/sqlpp/appendix_4_manual_data.md | 1 +
15 files changed, 575 insertions(+), 832 deletions(-)
diff --git a/asterixdb/asterix-doc/src/main/markdown/builtins/14_window.md b/asterixdb/asterix-doc/src/main/markdown/builtins/14_window.md
index e0e5948..67ead24 100644
--- a/asterixdb/asterix-doc/src/main/markdown/builtins/14_window.md
+++ b/asterixdb/asterix-doc/src/main/markdown/builtins/14_window.md
@@ -209,7 +209,7 @@ Window functions cannot appear in the FROM clause clause or LIMIT clause.
* Syntax:
- FIRST_VALUE(expr) [nulls-treatment] OVER (window-definition)
+ FIRST_VALUE(expr) [nulls-modifier] OVER (window-definition)
* Returns the requested value from the first tuple in the current window
frame, where the window frame is specified by the window definition.
@@ -221,7 +221,7 @@ Window functions cannot appear in the FROM clause clause or LIMIT clause.
* Modifiers:
- * [Nulls Treatment](manual.html#Nulls_treatment): (Optional) Determines how
+ * [NULLS Modifier](manual.html#Window_function_options): (Optional) Determines how
NULL or MISSING values are treated when finding the first value in the
window frame.
@@ -330,7 +330,7 @@ Window functions cannot appear in the FROM clause clause or LIMIT clause.
* Syntax:
- LAG(expr[, offset[, default]]) [nulls-treatment] OVER ([window-partition-clause] [window-order-clause])
+ LAG(expr[, offset[, default]]) [nulls-modifier] OVER ([window-partition-clause] [window-order-clause])
* Returns the value from a tuple at a given offset prior to the current tuple
position.
@@ -353,7 +353,7 @@ Window functions cannot appear in the FROM clause clause or LIMIT clause.
* Modifiers:
- * [Nulls Treatment](manual.html#Nulls_treatment): (Optional) Determines how
+ * [NULLS Modifier](manual.html#Window_function_options): (Optional) Determines how
NULL or MISSING values are treated when finding the offset tuple in the
window partition.
@@ -442,7 +442,7 @@ Window functions cannot appear in the FROM clause clause or LIMIT clause.
* Syntax:
- LAST_VALUE(expr) [nulls-treatment] OVER (window-definition)
+ LAST_VALUE(expr) [nulls-modifier] OVER (window-definition)
* Returns the requested value from the last tuple in the current window frame,
where the window frame is specified by the window definition.
@@ -454,7 +454,7 @@ Window functions cannot appear in the FROM clause clause or LIMIT clause.
* Modifiers:
- * [Nulls Treatment](manual.html#Nulls_treatment): (Optional) Determines how
+ * [NULLS Modifier](manual.html#Window_function_options): (Optional) Determines how
NULL or MISSING values are treated when finding the last tuple in the
window frame.
@@ -573,7 +573,7 @@ Window functions cannot appear in the FROM clause clause or LIMIT clause.
* Syntax:
- LEAD(expr[, offset[, default]]) [nulls-treatment] OVER ([window-partition-clause] [window-order-clause])
+ LEAD(expr[, offset[, default]]) [nulls-modifier] OVER ([window-partition-clause] [window-order-clause])
* Returns the value from a tuple at a given offset ahead of the current tuple
position.
@@ -596,7 +596,7 @@ Window functions cannot appear in the FROM clause clause or LIMIT clause.
* Modifiers:
- * [Nulls Treatment](manual.html#Nulls_treatment): (Optional) Determines how
+ * [NULLS Modifier](manual.html#Window_function_options): (Optional) Determines how
NULL or MISSING values are treated when finding the offset tuple in the
window partition.
@@ -685,7 +685,7 @@ Window functions cannot appear in the FROM clause clause or LIMIT clause.
* Syntax:
- NTH_VALUE(expr, offset) [nthval-from] [nulls-treatment] OVER (window-definition)
+ NTH_VALUE(expr, offset) [from-modifier] [nulls-modifier] OVER (window-definition)
* Returns the requested value from a tuple in the current window frame, where
the window frame is specified by the window definition.
@@ -700,7 +700,7 @@ Window functions cannot appear in the FROM clause clause or LIMIT clause.
* Modifiers:
- * [Nth Val From](manual.html#Nth_val_from): (Optional) Determines where the
+ * [FROM Modifier](manual.html#Window_function_options): (Optional) Determines where the
function starts counting the offset.
- `FROM FIRST`: Counting starts at the first tuple in the window frame.
@@ -714,7 +714,7 @@ Window functions cannot appear in the FROM clause clause or LIMIT clause.
The order of the tuples is determined by the window order clause.
If this modifier is omitted, the default is `FROM FIRST`.
- * [Nulls Treatment](manual.html#Nulls_treatment): (Optional) Determines how
+ * [NULLS Modifier](manual.html#Window_function_options): (Optional) Determines how
NULL or MISSING values are treated when finding the offset tuple in the
window frame.
diff --git a/asterixdb/asterix-doc/src/main/markdown/builtins/15_bitwise.md b/asterixdb/asterix-doc/src/main/markdown/builtins/15_bitwise.md
index e86f679..f3b5ba5 100644
--- a/asterixdb/asterix-doc/src/main/markdown/builtins/15_bitwise.md
+++ b/asterixdb/asterix-doc/src/main/markdown/builtins/15_bitwise.md
@@ -651,3 +651,4 @@ The function has an alias `isbitset`.
This returns 10 (1010 in binary) because 3 XOR 6 equals 5 (0101 in binary),
and then 5 XOR 15 equals 10 (1010 in binary).
+
diff --git a/asterixdb/asterix-doc/src/main/markdown/builtins/9_aggregate_sql.md b/asterixdb/asterix-doc/src/main/markdown/builtins/9_aggregate_sql.md
index 93f6d9a..0657fb0 100644
--- a/asterixdb/asterix-doc/src/main/markdown/builtins/9_aggregate_sql.md
+++ b/asterixdb/asterix-doc/src/main/markdown/builtins/9_aggregate_sql.md
@@ -25,12 +25,12 @@ The query language also supports standard SQL aggregate functions (e.g., `MIN`,
Note that these are not real functions in the query language, but just syntactic sugars over corresponding
builtin aggregate functions (e.g., `ARRAY_MIN`, `ARRAY_MAX`,
`ARRAY_SUM`, `ARRAY_COUNT`, and `ARRAY_AVG`).
-Refer to [SQL-92 Aggregation Functions](manual.html#SQL-92_aggregation_functions) for details.
+Refer to [Aggregation Pseudo-Functions](manual.html#Aggregation_PseudoFunctions) for details.
The `DISTINCT` keyword may be used with built-in aggregate functions and standard SQL aggregate functions.
It may also be used with aggregate functions used as window functions.
It determines whether the function aggregates all values in the group, or distinct values only.
-Refer to [Aggregation Functions](manual.html#Aggregation_functions) for details.
+Refer to [Function Calls](manual.html#Function_call_expressions) for details.
Aggregate functions may be used as window functions when they are used with an OVER clause.
Refer to [OVER Clauses](manual.html#Over_clauses) for details.
diff --git a/asterixdb/asterix-doc/src/main/markdown/datamodel/datamodel_composite.md b/asterixdb/asterix-doc/src/main/markdown/datamodel/datamodel_composite.md
index 92b0374..d8b1742 100644
--- a/asterixdb/asterix-doc/src/main/markdown/datamodel/datamodel_composite.md
+++ b/asterixdb/asterix-doc/src/main/markdown/datamodel/datamodel_composite.md
@@ -55,3 +55,4 @@ An example would be
{{"hello", 9328, "world", [1, 2, null]}}
+
diff --git a/asterixdb/asterix-doc/src/main/markdown/datamodel/datamodel_primitive_common.md b/asterixdb/asterix-doc/src/main/markdown/datamodel/datamodel_primitive_common.md
index 4c0b2e0..1f77a53 100644
--- a/asterixdb/asterix-doc/src/main/markdown/datamodel/datamodel_primitive_common.md
+++ b/asterixdb/asterix-doc/src/main/markdown/datamodel/datamodel_primitive_common.md
@@ -20,7 +20,7 @@
## <a id="PrimitiveTypes">Primitive Types</a> ##
### <a id="PrimitiveTypesBoolean">Boolean</a> ###
-`boolean` data type can have one of the two values: _*true*_ or _*false*_.
+`boolean` data type can have one of the two values: *true* or *false*.
* Example:
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/1_intro.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/1_intro.md
index 7b56e12..fda5516 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/1_intro.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/1_intro.md
@@ -17,7 +17,7 @@
! under the License.
!-->
-# <a id="Introduction">1. Introduction</a><font size="3"/>
+# <a id="Introduction">1. Introduction</a>
This document is intended as a reference guide to the full syntax and semantics of
AsterixDB's query language, a SQL-based language for working with semistructured data.
@@ -43,3 +43,4 @@ We list and briefly explain each of the productions in the query grammar, offeri
using two datasets named `customers` and `orders`. Each dataset is a collection of objects.
The contents of the example datasets can be found at the end of this manual in [Appendix 4](#Manual_data).
+For additional reading on SQL++ and more examples, refer to [SQL++ for SQL Users: A Tutorial](https://asterixdb.apache.org/files/SQL_Book.pdf).
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/2_expr.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/2_expr.md
index 4453099..de7f442 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/2_expr.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/2_expr.md
@@ -23,25 +23,16 @@ SQL++ is an orthogonal language, which means that expressions can serve as opera
In this section, we'll discuss the various kinds of SQL++ expressions.
----
-
-### Expr
-****
-
-
----
+##### Expr
+
## <a id="Operator_expressions">Operator Expressions</a>
Operators perform a specific operation on the input values or expressions.
The syntax of an operator expression is as follows:
----
-
-### OperatorExpr
-****
-
----
+##### OperatorExpr
+
The language provides a full set of operators that you can use within its statements.
Here are the categories of operators:
@@ -89,6 +80,7 @@ values.
| || | String concatenation | SELECT VALUE "ab"||"c"||"d"; |
### <a id="Collection_operators">Collection Operators</a>
+
Collection operators are used for membership tests (IN, NOT IN) or empty collection tests (EXISTS, NOT EXISTS).
| Operator | Purpose | Example |
@@ -99,20 +91,22 @@ Collection operators are used for membership tests (IN, NOT IN) or empty collect
| NOT EXISTS | Check whether a collection is empty | FROM orders AS o <br/>WHERE NOT EXISTS o.items <br/> SELECT *; |
### <a id="Comparison_operators">Comparison Operators</a>
+
Comparison operators are used to compare values.
+
The comparison operators fall into one of two sub-categories: missing value comparisons and regular value comparisons.
-SQL++ (and JSON) has two ways of representing missing information in an object - the presence of the field
+SQL++ (and JSON) has two ways of representing missing information in an object — the presence of the field
with a NULL for its value (as in SQL), and the absence of the field (which JSON permits).
For example, the first of the following objects represents Jack, whose friend is Jill.
-In the other examples, Jake is friendless a la SQL, with a friend field that is NULL, while Joe is friendless in a more
+In the other examples, Jake is friendless à la SQL, with a friend field that is NULL, while Joe is friendless in a more
natural (for JSON) way, i.e., by not having a friend field.
##### Examples
-{"name": "Jack", "friend": "Jill"}
+ {"name": "Jack", "friend": "Jill"}
-{"name": "Jake", "friend": NULL}
+ {"name": "Jake", "friend": NULL}
-{"name": "Joe"}
+ {"name": "Joe"}
The following table enumerates all of the comparison operators available in SQL++.
@@ -151,6 +145,7 @@ The following table summarizes how the missing value comparison operators work.
| IS NOT KNOWN (IS NOT VALUED) | FALSE | TRUE | TRUE |
### <a id="Logical_operators">Logical Operators</a>
+
Logical operators perform logical `NOT`, `AND`, and `OR` operations over Boolean values (`TRUE` and `FALSE`) plus `NULL` and `MISSING`.
| Operator | Purpose | Example |
@@ -186,13 +181,10 @@ The following table demonstrates the results of `NOT` on all possible inputs.
## <a id="Quantified_expressions">Quantified Expressions</a>
----
+##### QuantifiedExpr
+
-### QuantifiedExpr
-****
-##### Synonym for `SOME`: `ANY`
-
----
+Synonym for `SOME`: `ANY`
Quantified expressions are used for expressing existential or universal predicates involving the elements of a collection.
@@ -206,23 +198,21 @@ Otherwise, a type error will be raised if the first expression in a quantified e
##### Examples
- EVERY x IN [ 1, 2, 3 ] SATISFIES x < 3 Returns FALSE
- SOME x IN [ 1, 2, 3 ] SATISFIES x < 3 Returns TRUE
+ EVERY x IN [ 1, 2, 3 ] SATISFIES x < 3 -- ➊
+ SOME x IN [ 1, 2, 3 ] SATISFIES x < 3 -- ➋
+➀ Returns `FALSE`
+➁ Returns `TRUE`
## <a id="Path_expressions">Path Expressions</a>
----
-
-### PathExpr
-****
-
----
+##### PathExpr
+
Components of complex types in the data model are accessed via path expressions. Path access can be applied to the
result of a query expression that yields an instance of a complex type, for example, an object or an array instance.
-For objects, path access is based on field names, and it accesses the field whose name was specified.<br/>
+For objects, path access is based on field names, and it accesses the field whose name was specified.
For arrays, path access is based on (zero-based) array-style indexing. Array indices can be used to retrieve either a single element from an array, or a whole subset of an array. Accessing a single element is achieved by providing a single index argument (zero-based element position), while obtaining a subset of an array is achieved by
providing the `start` and `end` (zero-based) index positions; the returned subset is from position `start` to position
@@ -239,71 +229,56 @@ and also a composition thereof.
##### Examples
- ({"name": "MyABCs", "array": [ "a", "b", "c"]}).array Returns [["a", "b", "c"]]
-
- (["a", "b", "c"])[2] Returns ["c"]
-
- (["a", "b", "c"])[-1] Returns ["c"]
-
- ({"name": "MyABCs", "array": [ "a", "b", "c"]}).array[2] Returns ["c"]
-
- (["a", "b", "c"])[0:2] Returns [["a", "b"]]
-
- (["a", "b", "c"])[0:] Returns [["a", "b", "c"]]
-
- (["a", "b", "c"])[-2:-1] Returns [["b"]]
-
+ ({"name": "MyABCs", "array": [ "a", "b", "c"]}).array -- ➊
+ (["a", "b", "c"])[2] -- ➋
+ (["a", "b", "c"])[-1] -- ➌
+ ({"name": "MyABCs", "array": [ "a", "b", "c"]}).array[2] -- ➍
+ (["a", "b", "c"])[0:2] -- ➎
+ (["a", "b", "c"])[0:] -- ➏
+ (["a", "b", "c"])[-2:-1] -- ➐
+
+➀ Returns `[["a", "b", "c"]]`
+➁ Returns `["c"]`
+➂ Returns `["c"]`
+➃ Returns `["c"]`
+➄ Returns `[["a", "b"]]`
+➅ Returns `[["a", "b", "c"]]`
+➆ Returns `[["b"]]`
## <a id="Primary_expressions">Primary Expressions</a>
----
-
-### PrimaryExpr
-****
-
----
+##### PrimaryExpr
+
-The most basic building block for any expression in SQL++ is PrimaryExpression.
+The most basic building block for any expression in SQL++ is Primary Expression.
This can be a simple literal (constant) value, a reference to a query variable that is in scope, a parenthesized
expression, a function call, or a newly constructed instance of the data model (such as a newly constructed object,
array, or multiset of data model instances).
### <a id="Literals">Literals</a>
----
-
-### Literal
-****
-
----
+##### Literal
+
The simplest kind of expression is a literal that directly represents a value in JSON format. Here are some examples:
-
-
- -42
- "Hello"
- true
- false
- null
-
+ -42
+ "Hello"
+ true
+ false
+ null
Numeric literals may include a sign and an optional decimal point. They may also be written in exponential notation, like this:
-
- 5e2
- -4.73E-2
-
-
+ 5e2
+ -4.73E-2
String literals may be enclosed in either single quotes or double quotes. Inside a string literal, the delimiter character for that string must be "escaped" by a backward slash, as in these examples:
+ "I read \"War and Peace\" today."
+ 'I don\'t believe everything I read.'
-
- "I read \"War and Peace\" today."
- 'I don\'t believe everything I read.'
-
-The table below shows how to escape characters in SQL++
+The table below shows how to escape characters in SQL++.
|Character Name |Escape Method
|----------|----------------|
@@ -317,19 +292,15 @@ The table below shows how to escape characters in SQL++
|CarriageReturn|`\r`|
|EscapeTab|`\t`|
-
-
### <a id="Variable_references">Identifiers and Variable References</a>
-
Like SQL, SQL++ makes use of a language construct called an *identifier*. An identifier starts with an alphabetic character or the underscore character _ , and contains only case-sensitive alphabetic characters, numeric digits, or the special characters _ and $. It is also possible for an identifier to include other special characters, or to be the same as a reserved word, by enclosing the identifier in back-ticks (it's then called a *delimited identifier*). Identifiers are used in varia [...]
- X
- customer_name
- `SELECT`
- `spaces in here`
- `@&#`
-
+ X
+ customer_name
+ `SELECT`
+ `spaces in here`
+ `@&#`
A very simple kind of SQL++ expression is a variable, which is simply an identifier. As in SQL, a variable can be bound to a value, which may be an input dataset, some intermediate result during processing of a query, or the final result of a query. We'll learn more about variables when we discuss queries.
@@ -339,9 +310,9 @@ Note that the SQL++ rules for delimiting strings and identifiers are different f
A parameter reference is an external variable. Its value is provided using the [statement execution API](../api.html#queryservice).
-Parameter references come in two forms, *Named Parameter References* and *Positional Parameter References.*
+Parameter references come in two forms, *Named Parameter References* and *Positional Parameter References*.
-Named paramater references consist of the "$" symbol followed by an identifier or delimited identifier.
+Named parameter references consist of the "$" symbol followed by an identifier or delimited identifier.
Positional parameter references can be either a "$" symbol followed by one or more digits or a "?" symbol. If numbered, positional parameters start at 1. "?" parameters are interpreted as $1 to $N based on the order in which they appear in the statement.
@@ -357,20 +328,15 @@ An error will be raised in the parameter is not bound at query execution time.
### <a id="Parenthesized_expressions">Parenthesized Expressions</a>
----
-
-### ParenthesizedExpr
-****
-
-### Subquery
-****
+##### ParenthesizedExpr
+
----
+##### Subquery
+
An expression can be parenthesized to control the precedence order or otherwise clarify a query.
A [subquery](#Subqueries) (nested [selection](#Union_all)) may also be enclosed in parentheses. For more on these topics please see their respective sections.
-
The following expression evaluates to the value 2.
##### Example
@@ -379,21 +345,17 @@ The following expression evaluates to the value 2.
### <a id="Function_call_expressions">Function Calls</a>
----
-
-### FunctionCall
-****
-
-### OrdinaryFunctionCall
-****
+##### FunctionCall
+
-### AggregateFunctionCall
-****
+##### OrdinaryFunctionCall
+
-### DataverseName
-****
+##### AggregateFunctionCall
+
----
+##### DataverseName
+
Functions are included in SQL++, like most languages, as a way to package useful functionality or to
componentize complicated or reusable computations.
@@ -411,20 +373,16 @@ The following example is a function call expression whose value is 8.
length('a string')
-## <a id="Case_expressions">Case Expressions</a>
+### <a id="Case_expressions">Case Expressions</a>
----
+##### CaseExpr
+
-### CaseExpr
-****
+##### SimpleCaseExpr
+
-### SimpleCaseExpr
-****
-
-### SearchedCaseExpr
-****
-
----
+##### SearchedCaseExpr
+
In a simple `CASE` expression, the query evaluator searches for the first `WHEN` ... `THEN` pair in which the `WHEN` expression is equal to the expression following `CASE` and returns the expression following `THEN`. If none of the `WHEN` ... `THEN` pairs meet this condition, and an `ELSE` branch exists, it returns the `ELSE` expression. Otherwise, `NULL` is returned.
@@ -439,63 +397,54 @@ The following example illustrates the form of a case expression.
### <a id="Constructors">Constructors</a>
----
-
-### Constructor
-****
-
-### ObjectConstructor
-****
+##### Constructor
+
-### ArrayConstructor
-****
+##### ObjectConstructor
+
-### MultisetConstructor
-****
+##### ArrayConstructor
+
----
+##### MultisetConstructor
+
Structured JSON values can be represented by constructors, as in these examples:
- An object: { "name": "Bill", "age": 42 }
- An array: [ 1, 2, "Hello", null ]
-
-In a constructed object, the names of the fields must be strings (either literal strings or computed strings), and an object may not contain any duplicate names. Of course, structured literals can be nested, as in this example:
-
+ { "name": "Bill", "age": 42 } -- ➊
+ [ 1, 2, "Hello", null ] -- ➋
+➀ An object
+➁ An array
- [ {"name": "Bill",
- "address":
- {"street": "25 Main St.",
- "city": "Cincinnati, OH"
- }
- },
- {"name": "Mary",
- "address":
- {"street": "107 Market St.",
- "city": "St. Louis, MO"
- }
- }
- ]
-
+In a constructed object, the names of the fields must be strings (either literal strings or computed strings), and an object may not contain any duplicate names. Of course, structured literals can be nested, as in this example:
+ [ {"name": "Bill",
+ "address":
+ {"street": "25 Main St.",
+ "city": "Cincinnati, OH"
+ }
+ },
+ {"name": "Mary",
+ "address":
+ {"street": "107 Market St.",
+ "city": "St. Louis, MO"
+ }
+ }
+ ]
The array items in an array constructor, and the field-names and field-values in an object constructor, may be represented by expressions. For example, suppose that the variables firstname, lastname, salary, and bonus are bound to appropriate values. Then structured values might be constructed by the following expressions:
-
-
An object:
- {
- "name": firstname || " " || lastname,
- "income": salary + bonus
- }
-
+ {
+ "name": firstname || " " || lastname,
+ "income": salary + bonus
+ }
An array:
- ["1984", lastname, salary + bonus, null]
-
+ ["1984", lastname, salary + bonus, null]
If only one expression is specified instead of the field-name/field-value pair in an object constructor then this
expression is supposed to provide the field value. The field name is then automatically generated based on the
@@ -509,16 +458,16 @@ kind of the value expression as in Q2.1:
##### Example
(Q2.1)
- FROM customers AS c
- WHERE c.custid = "C47"
- SELECT VALUE {c.name, c.rating}
+ FROM customers AS c
+ WHERE c.custid = "C47"
+ SELECT VALUE {c.name, c.rating}
This query outputs:
+ [
+ {
+ "name": "S. Logan",
+ "rating": 625
+ }
+ ]
- [
- {
- "name": "S. Logan",
- "rating": 625
- }
- ]
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query.md
index f4bbc4d..3e70922 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query.md
@@ -17,27 +17,42 @@
! under the License.
!-->
+A *query* can be an expression, or it can be constructed from blocks of code called *query blocks*. A query block may contain several clauses, including `SELECT`, `FROM`, `LET`, `WHERE`, `GROUP BY`, and `HAVING`.
+
+##### Query
+
+
+##### Selection
+
+
+##### QueryBlock
+
+
+##### StreamGenerator
+
+
+Note that, unlike SQL, SQL++ allows the `SELECT` clause to appear either at the beginning or at the end of a query block. For some queries, placing the `SELECT` clause at the end may make a query block easier to understand, because the `SELECT` clause refers to variables defined in the other clauses.
+
## <a id="Select_clauses">SELECT Clause</a>
----
-### SelectClause
-****
+##### SelectClause
+
-### Projection
-****
+##### Projection
+
-##### Synonyms for `VALUE`: `ELEMENT`, `RAW`
----
+Synonyms for `VALUE`: `ELEMENT`, `RAW`
In a query block, the `FROM`, `WHERE`, `GROUP BY`, and `HAVING` clauses (if present) are collectively called the Stream Generator. All these clauses, taken together, generate a stream of tuples of bound variables. The `SELECT` clause then uses these bound variables to generate the output of the query block.
-For example, the clause `FROM customers AS c` scans over the `customers` collection, binding the variable `c` to each customer` object in turn, producing a stream of bindings.
+For example, the clause `FROM customers AS c` scans over the `customers` collection, binding the variable `c` to each `customer` object in turn, producing a stream of bindings.
Here's a slightly more complex example of a stream generator:
##### Example
- FROM customers AS c, orders AS o
- WHERE c.custid = o.custid
+
+ FROM customers AS c, orders AS o
+ WHERE c.custid = o.custid
In this example, the `FROM` clause scans over the customers and orders collections, producing a stream of variable pairs (`c`, `o`) in which `c` is bound to a `customer` object and `o` is bound to an `order` object. The `WHERE` clause then retains only those pairs in which the custid values of the two objects match.
@@ -49,12 +64,12 @@ In SQL++, the `SELECT` clause may appear either at the beginning or at the end o
### <a id="Select_element">SELECT VALUE</a>
-
The `SELECT VALUE` clause returns an array or multiset that contains the results of evaluating the `VALUE` expression, with one evaluation being performed per "binding tuple" (i.e., per `FROM` clause item) satisfying the statement's selection criteria.
If there is no `FROM` clause, the expression after `VALUE` is evaluated once with no binding tuples
(except those inherited from an outer environment).
##### Example
+
(Q3.1)
SELECT VALUE 1;
@@ -66,6 +81,7 @@ Result:
]
##### Example
+
(Q3.2) The following query returns the names of all customers whose rating is above 650.
FROM customers AS c
@@ -74,7 +90,6 @@ Result:
Result:
- RESULT:
[
"T. Cody",
"M. Sinclair",
@@ -87,13 +102,14 @@ Result:
Traditional SQL-style `SELECT` syntax is also supported in SQL++, however the result of a query is not guaranteed to preserve the order of expressions in the `SELECT` clause.
##### Example
+
(Q3.3) The following query returns the names and customers ids of any customers whose rating is 750.
FROM customers AS c
WHERE c.rating = 750
SELECT c.name AS customer_name, c.custid AS customer_id;
-Returns:
+Result:
[
{
@@ -110,25 +126,23 @@ Returns:
As in SQL, the phrase `SELECT *` suggests, "select everything."
-
For each binding tuple in the stream, `SELECT *` produces an output object. For each variable in the binding tuple, the output object contains a field: the name of the field is the name of the variable, and the value of the field is the value of the variable. Essentially, `SELECT *` means, "return all the bound variables, with their names and values."
-
The effect of `SELECT *` can be illustrated by an example based on two small collections named `ages` and `eyes`. The contents of the two collections are as follows:
`ages`:
- [
- { "name": "Bill", "age": 21 },
- { "name": "Sue", "age": 32 }
- ]
+ [
+ { "name": "Bill", "age": 21 },
+ { "name": "Sue", "age": 32 }
+ ]
`eyes`:
- [
- { "name": "Bill", "eyecolor": "brown" },
- { "name": "Sue", "eyecolor": "blue" }
- ]
+ [
+ { "name": "Bill", "eyecolor": "brown" },
+ { "name": "Sue", "eyecolor": "blue" }
+ ]
The following example applies `SELECT *` to a single collection.
@@ -136,17 +150,17 @@ The following example applies `SELECT *` to a single collection.
(Q3.4a) Return all the information in the `ages` collection.
- FROM ages AS a
- SELECT * ;
+ FROM ages AS a
+ SELECT * ;
Result:
- [
- { "a": { "name": "Bill", "age": 21 },
- },
- { "a": { "name": "Sue", "age": 32}
- }
- ]
+ [
+ { "a": { "name": "Bill", "age": 21 },
+ },
+ { "a": { "name": "Sue", "age": 32}
+ }
+ ]
Note that the variable-name `a` appears in the query result. If the `FROM` clause had been simply `FROM ages` (omitting `AS a`), the variable-name in the query result would have been `ages`.
@@ -156,26 +170,28 @@ The next example applies `SELECT *` to a join of two collections.
(Q3.4b) Return all the information in a join of `ages` and `eyes` on matching name fields.
- FROM ages AS a, eyes AS e
- WHERE a.name = e.name
- SELECT * ;
+ FROM ages AS a, eyes AS e
+ WHERE a.name = e.name
+ SELECT * ;
Result:
- [
- { "a": { "name": "Bill", "age": 21 },
- "e": { "name": "Bill", "eyecolor": "Brown" }
- },
- { "a": { "name": "Sue", "age": 32 },
- "e": { "name": "Sue", "eyecolor": "Blue" }
- }
- ]
+ [
+ { "a": { "name": "Bill", "age": 21 },
+ "e": { "name": "Bill", "eyecolor": "Brown" }
+ },
+ { "a": { "name": "Sue", "age": 32 },
+ "e": { "name": "Sue", "eyecolor": "Blue" }
+ }
+ ]
Note that the result of `SELECT *` in SQL++ is more complex than the result of `SELECT *` in SQL.
### <a id="Select_variable_star">SELECT _variable_.*</a>
-SQL++ has an alternative version of `SELECT *` in which the star is preceded by a variable. Whereas `SELECT *` means, "return all the bound variables, with their names and values," `SELECT` *variable* `.*` means "return only the named variable, and return only its value, not its name."
+SQL++ has an alternative version of `SELECT *` in which the star is preceded by a variable.
+
+Whereas the version without a named variable means, "return all the bound variables, with their names and values," `SELECT` *variable* `.*` means "return only the named variable, and return only its value, not its name."
The following example can be compared with (Q3.4a) to see the difference between the two versions of `SELECT *`:
@@ -183,37 +199,39 @@ The following example can be compared with (Q3.4a) to see the difference between
(Q3.4c) Return all information in the `ages` collection.
- FROM ages AS a
- SELECT a.*
+ FROM ages AS a
+ SELECT a.*
Result:
- [
- { "name": "Bill", "age": 21 },
- { "name": "Sue", "age": 32 }
- ]
+ [
+ { "name": "Bill", "age": 21 },
+ { "name": "Sue", "age": 32 }
+ ]
-Note that, for queries over a single collection, `SELECT` *variable* `.*` returns a simpler result and therefore may be preferable to `SELECT *`. In fact, `SELECT` *variable* `.*`, like `SELECT *` in SQL, is equivalent to a `SELECT` clause that enumerates all the fields of the collection, as in (Q3.4d):
+Note that, for queries over a single collection, `SELECT` *variable* `.*` returns a simpler result and therefore may be preferable to `SELECT *`.
+
+In fact, `SELECT` *variable* `.*`, like `SELECT *` in SQL, is equivalent to a `SELECT` clause that enumerates all the fields of the collection, as in (Q3.4d):
##### Example
(Q3.4d) Return all the information in the `ages` collection.
- FROM ages AS a
- SELECT a.name, a.age
+ FROM ages AS a
+ SELECT a.name, a.age
(same result as (Q3.4c))
- `SELECT` *variable* `.*` has an additional application. It can be used to return all the fields of a nested object. To illustrate this use, we will use the `customers` dataset in the example database (see Appendix 4).
+`SELECT` *variable* `.*` has an additional application. It can be used to return all the fields of a nested object. To illustrate this use, we will use the `customers` dataset in the example database — see [Appendix 4](#Manual_data).
##### Example
+
(Q3.4e) In the `customers` dataset, return all the fields of the `address` objects that have zipcode "02340".
FROM customers AS c
WHERE c.address.zipcode = "02340"
SELECT address.* ;
-
Result:
[
@@ -224,8 +242,8 @@ Result:
}
]
-
### <a id="Select_distinct">SELECT DISTINCT</a>
+
The `DISTINCT` keyword is used to eliminate duplicate items from the results of a query block.
##### Example
@@ -253,6 +271,7 @@ Result:
]
### <a id="Unnamed_projections">Unnamed Projections</a>
+
Similar to standard SQL, the query language supports unnamed projections (a.k.a, unnamed `SELECT` clause items), for which names are generated rather than user-provided.
Name generation has three cases:
@@ -284,7 +303,8 @@ Result:
In the result, `$1` is the generated name for `o.orderno % 1000`, while `order_date` is the generated name for `o.order_date`. It is good practice, however, to not rely on the randomly generated names which can be confusing and irrelevant. Instead, practice good naming conventions by providing a meaningful and concise name which properly describes the selected item.
### <a id="Abbreviated_field_access_expressions">Abbreviated Field Access Expressions</a>
-As in standard SQL, field access expressions can be abbreviated when there is no ambiguity. In the next example, the variable `o` is the only possible variable reference for fields `orderno` and `order_date` and thus could be omitted in the query. This practice is not recommended, however, as queries may have fields (such as `custid`) which can be present in multiple datasets. More information on abbbreviated field access can be found in the appendix section on Variable Resolution.
+
+As in standard SQL, field access expressions can be abbreviated when there is no ambiguity. In the next example, the variable `o` is the only possible variable reference for fields `orderno` and `order_date` and thus could be omitted in the query. This practice is not recommended, however, as queries may have fields (such as `custid`) which can be present in multiple datasets. More information on abbreviated field access can be found in the appendix section on Variable Resolution.
##### Example
@@ -307,28 +327,24 @@ Result:
}
]
+## <a id="From_clauses">FROM Clause</a>
-## <a id="From_clauses">FROM clause</a>
-
----
+##### FromClause
+
-### FromClause
-****
+##### FromTerm
+
-### FromTerm
-****
+##### NamedExpr
+
-### NamedExpr
-****
+##### JoinStep
+
-### JoinStep
-****
+##### UnnestStep
+
-### UnnestStep
-****
-
-##### Synonyms for `UNNEST`: `CORRELATE`, `FLATTEN`
----
+Synonyms for `UNNEST`: `CORRELATE`, `FLATTEN`
The purpose of a `FROM` clause is to iterate over a collection, binding a variable to each item in turn. Here's a query that iterates over the `customers` dataset, choosing certain customers and returning some of their attributes.
@@ -336,19 +352,13 @@ The purpose of a `FROM` clause is to iterate over a collection, binding a variab
(Q3.8) List the customer ids and names of the customers in zipcode 63101, in order by their customer IDs.
-
-
FROM customers
WHERE address.zipcode = "63101"
SELECT custid AS customer_id, name
ORDER BY customer_id;
-
-
Result:
-
-
[
{
"customer_id": "C13",
@@ -373,35 +383,26 @@ You may also provide an explicit iteration variable, as in this version of the s
(Q3.9) Alternative version of Q3.8 (same result).
-
-
FROM customers AS c
WHERE c.address.zipcode = "63101"
SELECT c.custid AS customer_id, c.name
ORDER BY customer_id;
-
In Q3.9, the variable `c` is bound to each `customer` object in turn as the query iterates over the `customers` dataset. An explicit iteration variable can be used to identify the fields of the referenced object, as in `c.name` in the `SELECT` clause of Q3.9. When referencing a field of an object, the iteration variable can be omitted when there is no ambiguity. For example, `c.name` could be replaced by `name` in the `SELECT` clause of Q3.9. That's why field-names like `name` and `custi [...]
-
-
In the examples above, the `FROM` clause iterates over the objects in a dataset. But in general, a `FROM` clause can iterate over any collection. For example, the objects in the `orders` dataset each contain a field called `items`, which is an array of nested objects. In some cases, you will write a `FROM` clause that iterates over a nested array like `items`.
-
The stream of objects (more accurately, variable bindings) that is produced by the `FROM` clause does not have any particular order. The system will choose the most efficient order for the iteration. If you want your query result to have a specific order, you must use an `ORDER BY` clause.
-
It's good practice to specify an explicit iteration variable for each collection in the `FROM` clause, and to use these variables to qualify the field-names in other clauses. Here are some reasons for this convention:
+ - It's nice to have different names for the collection as a whole and an object in the collection. For example, in the clause `FROM customers AS c`, the name `customers` represents the dataset and the name `c` represents one object in the dataset.
-- It's nice to have different names for the collection as a whole and an object in the collection. For example, in the clause `FROM customers AS c`, the name `customers` represents the dataset and the name `c` represents one object in the dataset.
-
-- In some cases, iteration variables are required. For example, when joining a dataset to itself, distinct iteration variables are required to distinguish the left side of the join from the right side.
-
-- In a subquery it's sometimes necessary to refer to an object in an outer query block (this is called a *correlated subquery*). To avoid confusion in correlated subqueries, it's best to use explicit variables.
+ - In some cases, iteration variables are required. For example, when joining a dataset to itself, distinct iteration variables are required to distinguish the left side of the join from the right side.
+ - In a subquery it's sometimes necessary to refer to an object in an outer query block (this is called a *correlated subquery*). To avoid confusion in correlated subqueries, it's best to use explicit variables.
-### <a id="Left_outer_unnests">Joins</a>
+### <a id="Join_clauses">Joins</a>
A `FROM` clause gets more interesting when there is more than one collection involved. The following query iterates over two collections: `customers` and `orders`. The `FROM` clause produces a stream of binding tuples, each containing two variables, `c` and `o`. In each binding tuple, `c` is bound to an object from `customers`, and `o` is bound to an object from `orders`. Conceptually, at this point, the binding tuple stream contains all possible pairs of a customer and an order (this is [...]
@@ -409,7 +410,6 @@ A `FROM` clause gets more interesting when there is more than one collection inv
(Q3.10) Create a packing list for order number 1001, showing the customer name and address and all the items in the order.
-
FROM customers AS c, orders AS o
WHERE c.custid = o.custid
AND o.orderno = 1001
@@ -418,7 +418,6 @@ A `FROM` clause gets more interesting when there is more than one collection inv
c.address,
o.items AS items_ordered;
-
Result:
[
@@ -445,16 +444,12 @@ Result:
}
]
-
-
Q3.10 is called a *join query* because it joins the `customers` collection and the `orders` collection, using the join condition `c.custid = o.custid`. In SQL++, as in SQL, you can express this query more explicitly by a `JOIN` clause that includes the join condition, as follows:
-
##### Example
(Q3.11) Alternative statement of Q3.10 (same result).
-
FROM customers AS c JOIN orders AS o
ON c.custid = o.custid
WHERE o.orderno = 1001
@@ -463,10 +458,8 @@ Q3.10 is called a *join query* because it joins the `customers` collection and t
c.address,
o.items AS items_ordered;
-
Whether you express the join condition in a `JOIN` clause or in a `WHERE` clause is a matter of taste; the result is the same. This manual will generally use a comma-separated list of collection-names in the `FROM` clause, leaving the join condition to be expressed elsewhere. As we'll soon see, in some query blocks the join condition can be omitted entirely.
-
There is, however, one case in which an explicit `JOIN` clause is necessary. That is when you need to join collection A to collection B, and you want to make sure that every item in collection A is present in the query result, even if it doesn't match any item in collection B. This kind of query is called a *left outer join*, and it is illustrated by the following example.
##### Example
@@ -479,8 +472,6 @@ There is, however, one case in which an explicit `JOIN` clause is necessary. Tha
SELECT c.custid, c.name, o.orderno, o.order_date
ORDER BY c.custid, o.order_date;
-
-
Result:
[
@@ -514,7 +505,6 @@ Result:
}
]
-
As you can see from the result of this left outer join, our data includes four orders from customer T. Cody, but no orders from customer M. Sinclair. The behavior of left outer join in SQL++ is different from that of SQL. SQL would have provided M. Sinclair with an order in which all the fields were `null`. SQL++, on the other hand, deals with schemaless data, which permits it to simply omit the order fields from the outer join.
Now we're ready to look at a new kind of join that was not provided (or needed) in original SQL. Consider this query:
@@ -523,8 +513,6 @@ Now we're ready to look at a new kind of join that was not provided (or needed)
(Q3.13) For every case in which an item is ordered in a quantity greater than 100, show the order number, date, item number, and quantity.
-
-
FROM orders AS o, o.items AS i
WHERE i.qty > 100
SELECT o.orderno, o.order_date, i.itemno AS item_number,
@@ -554,11 +542,8 @@ Result:
}
]
-
Q3.13 illustrates a feature called *left-correlation* in the `FROM` clause. Notice that we are joining `orders`, which is a dataset, to `items`, which is an array nested inside each order. In effect, for each order, we are unnesting the `items` array and joining it to the `order` as though it were a separate collection. For this reason, this kind of query is sometimes called an *unnesting query*. The keyword `UNNEST` may be used whenever left-correlation is used in a `FROM` clause, as sh [...]
-
-
##### Example
(Q3.14) Alternative statement of Q3.13 (same result).
@@ -569,38 +554,27 @@ Q3.13 illustrates a feature called *left-correlation* in the `FROM` clause. Noti
i.qty AS quantity
ORDER BY o.orderno, item_number;
-
The results of Q3.13 and Q3.14 are exactly the same. `UNNEST` serves as a reminder that left-correlation is being used to join an object with its nested items. The join condition in Q3.14 is expressed by the left-correlation: each order `o` is joined to its own items, referenced as `o.items`. The result of the `FROM` clause is a stream of binding tuples, each containing two variables, `o` and `i`. The variable `o` is bound to an order and the variable `i` is bound to one item inside that order.
Like `JOIN`, `UNNEST` has a `LEFT OUTER` option. Q3.14 could have specified:
-
-
- FROM orders AS o LEFT OUTER UNNEST o.items AS i
-
-
+ FROM orders AS o LEFT OUTER UNNEST o.items AS i
In this case, orders that have no nested items would appear in the query result.
## <a id="Let_clauses">LET Clause</a>
----
-
-### LetClause
-****
+##### LetClause
+
-##### Synonyms for `LET`: `LETTING`
----
+Synonyms for `LET`: `LETTING`
-
- `LET` clauses can be useful when a (complex) expression is used several times within a query, allowing it to be written once to make the query more concise. The word `LETTING` can also be used, although this is not as common. The next query shows an example.
+`LET` clauses can be useful when a (complex) expression is used several times within a query, allowing it to be written once to make the query more concise. The word `LETTING` can also be used, although this is not as common. The next query shows an example.
##### Example
(Q3.15) For each item in an order, the revenue is defined as the quantity times the price of that item. Find individual items for which the revenue is greater than 5000. For each of these, list the order number, item number, and revenue, in descending order by revenue.
-
-
FROM orders AS o, o.items AS i
LET revenue = i.qty * i.price
WHERE revenue > 5000
@@ -627,58 +601,47 @@ Result:
}
]
-
The expression for computing revenue is defined once in the `LET` clause and then used three times in the remainder of the query. Avoiding repetition of the revenue expression makes the query shorter and less prone to errors.
## <a id="Where_having_clauses">WHERE Clause</a>
----
-
-### WhereClause
-****
-
-
----
+##### WhereClause
+
The purpose of a `WHERE` clause is to operate on the stream of binding tuples generated by the `FROM` clause, filtering out the tuples that do not satisfy a certain condition. The condition is specified by an expression based on the variable names in the binding tuples. If the expression evaluates to true, the tuple remains in the stream; if it evaluates to anything else, including `null` or `missing`, it is filtered out. The surviving tuples are then passed along to the next clause to b [...]
Often, the expression in a `WHERE` clause is some kind of comparison like `quantity > 100`. However, any kind of expression is allowed in a `WHERE` clause. The only thing that matters is whether the expression returns `true` or not.
-
-## <a id="Group_By_clauses">Grouping</a>
+## <a id="Grouping">Grouping</a>
Grouping is especially important when manipulating hierarchies like the ones that are often found in JSON data. Often you will want to generate output data that includes both summary data and line items within the summaries. For this purpose, SQL++ supports several important extensions to the traditional grouping features of SQL. The familiar `GROUP BY` and `HAVING` clauses are still there, and they are joined by a new clause called `GROUP AS`. We'll illustrate these clauses by a series [...]
-### <a id="Left_outer_unnests">GROUP BY Clause</a>
-
----
-
-### GroupByClause
-****
+### <a id="Group_By_clauses">GROUP BY Clause</a>
-### GroupingElement
-****
+##### GroupByClause
+
-### OrdinaryGroupingSet
-****
+##### GroupingElement
+
-### NamedExpr
-****
+##### OrdinaryGroupingSet
+
----
+##### NamedExpr
+
We'll begin our discussion of grouping with an example from ordinary SQL.
##### Example
- (Q3.16) List the number of orders placed by each customer who has placed an order.
+(Q3.16) List the number of orders placed by each customer who has placed an order.
SELECT o.custid, COUNT(o.orderno) AS `order count`
FROM orders AS o
GROUP BY o.custid
ORDER BY o.custid;
- Result:
+Result:
[
{
@@ -702,13 +665,14 @@ We'll begin our discussion of grouping with an example from ordinary SQL.
"custid": "C41"
}
]
- The input to a `GROUP BY` clause is the stream of binding tuples generated by the `FROM` and `WHERE`clauses. In this query, before grouping, the variable `o` is bound to each object in the `orders` collection in turn.
- SQL++ evaluates the expression in the `GROUP BY` clause, called the grouping expression, once for each of the binding tuples. It then organizes the results into groups in which the grouping expression has a common value (as defined by the `=` operator). In this example, the grouping expression is `o.custid`, and each of the resulting groups is a set of `orders` that have the same `custid`. If necessary, a group is formed for `orders` in which `custid` is `null`, and another group is for [...]
+The input to a `GROUP BY` clause is the stream of binding tuples generated by the `FROM` and `WHERE`clauses. In this query, before grouping, the variable `o` is bound to each object in the `orders` collection in turn.
+
+SQL++ evaluates the expression in the `GROUP BY` clause, called the grouping expression, once for each of the binding tuples. It then organizes the results into groups in which the grouping expression has a common value (as defined by the `=` operator). In this example, the grouping expression is `o.custid`, and each of the resulting groups is a set of `orders` that have the same `custid`. If necessary, a group is formed for `orders` in which `custid` is `null`, and another group is form [...]
In the `GROUP BY`clause, you may optionally define an alias for the grouping expression. For example, in Q3.16, you could have written `GROUP BY o.custid AS cid`. The alias `cid` could then be used in place of the grouping expression in later clauses. In cases where the grouping expression contains an operator, it is especially helpful to define an alias (for example, `GROUP BY salary + bonus AS pay)`.
- Q3.16 had a single grouping expression, `o.custid`. If a query has multiple grouping expressions, the combination of grouping expressions is evaluated for every binding tuple, and the stream of binding tuples is partitioned into groups that have values in common for all of the grouping expressions. We'll see an example of such a query in Q3.18.
+Q3.16 had a single grouping expression, `o.custid`. If a query has multiple grouping expressions, the combination of grouping expressions is evaluated for every binding tuple, and the stream of binding tuples is partitioned into groups that have values in common for all of the grouping expressions. We'll see an example of such a query in Q3.18.
After grouping, the number of binding tuples is reduced: instead of a binding tuple for each of the input objects, there is a binding tuple for each group. The grouping expressions (identified by their aliases, if any) are bound to the results of their evaluations. However, all the non-grouping fields (that is, fields that were not named in the grouping expressions), are accessible only in a special way: as an argument of one of the special aggregation pseudo-functions such as: `SUM`, `A [...]
@@ -717,14 +681,14 @@ You may notice that the results of Q3.16 do not include customers who have no `o
##### Example
- (Q3.17) List the number of orders placed by each customer including those customers who have placed no orders.
+(Q3.17) List the number of orders placed by each customer including those customers who have placed no orders.
SELECT c.custid, c.name, COUNT(o.orderno) AS `order count`
FROM customers AS c LEFT OUTER JOIN orders AS o ON c.custid = o.custid
GROUP BY c.custid, c.name
ORDER BY c.custid;
- Result:
+Result:
[
{
@@ -764,7 +728,6 @@ You may notice that the results of Q3.16 do not include customers who have no `o
}
]
-
Notice in Q3.17 what happens when the special aggregation function `COUNT` is applied to a collection that does not exist, such as the orders of M. Sinclair: it returns zero. This behavior is unlike that of the other special aggregation functions `SUM`, `AVG`, `MAX`, and `MIN`, which return `null` if their operand does not exist. This should make you cautious about the `COUNT` function: If it returns zero, that may mean that the collection you are counting has zero members, or that it do [...]
Q3.17 also shows how a query block can have more than one grouping expression. In general, the `GROUP BY`clause produces a binding tuple for each different combination of values for the grouping expressions. In Q3.17, the `c.custid` field uniquely identifies a customer, so adding `c.name` as a grouping expression does not result in any more groups. Nevertheless, `c.name` must be included as a grouping expression if it is to be referenced outside (after) the `GROUP BY` clause. If `c.name` [...]
@@ -807,7 +770,6 @@ Q3.19 also shows how a `LET` clause can be used after a `GROUP BY` clause to def
(Q3.19) For each order, define the total revenue of the order as the sum of quantity times price for all the items in that order. List the total revenue for all the orders placed by the customer with id "C13", in descending order by total revenue.
-
FROM orders as o, o.items as i
WHERE o.custid = "C13"
GROUP BY o.orderno
@@ -832,21 +794,15 @@ Result:
}
]
-### <a id="Left_outer_unnests">HAVING Clause</a>
-
----
+### <a id="Having_clauses">HAVING Clause</a>
-### HavingClause
-****
-
-
----
+##### HavingClause
+
The `HAVING` clause is very similar to the `WHERE` clause, except that it comes after `GROUP BY` and applies a filter to groups rather than to individual objects. Here's an example of a `HAVING` clause that filters orders by applying a condition to their nested arrays of `items`.
By adding a `HAVING` clause to Q3.19, we can filter the results to include only those orders whose total revenue is greater than 1000, as shown in Q3.22.
-
##### Example
(Q3.20) Modify Q3.19 to include only orders whose total revenue is greater than 5000.
@@ -872,27 +828,30 @@ Result:
SQL provides several special functions for performing aggregations on groups including: `SUM`, `AVG`, `MAX`, `MIN`, and `COUNT` (some implementations provide more). These same functions are supported in SQL++. However, it's worth spending some time on these special functions because they don't behave like ordinary functions. They are called "pseudo-functions" here because they don't evaluate their operands in the same way as ordinary functions. To see the difference, consider these two e [...]
-##### Example 1:
+##### Example 1
SELECT LENGTH(name) FROM customers
- In Example 1, `LENGTH` is an ordinary function. It simply evaluates its operand (name) and then returns a result computed from the operand.
+In Example 1, `LENGTH` is an ordinary function. It simply evaluates its operand (name) and then returns a result computed from the operand.
+
+##### Example 2
-##### Example 2:
SELECT AVG(rating) FROM customers
The effect of `AVG` in Example 2 is quite different. Rather than performing a computation on an individual rating value, `AVG` has a global effect: it effectively restructures the query. As a pseudo-function, `AVG` requires its operand to be a group; therefore, it automatically collects all the rating values from the query block and forms them into a group.
The aggregation pseudo-functions always require their operand to be a group. In some queries, the group is explicitly generated by a `GROUP BY` clause, as in Q3.21:
+
##### Example
- (Q3.21) List the average credit rating of customers by zipcode.
+
+(Q3.21) List the average credit rating of customers by zipcode.
FROM customers AS c
GROUP BY c.address.zipcode AS zip
SELECT zip, AVG(c.rating) AS `avg credit rating`
ORDER BY zip;
- Result:
+Result:
[
{
@@ -915,10 +874,10 @@ The aggregation pseudo-functions always require their operand to be a group. In
Note in the result of Q3.21 that one or more customers had no zipcode. These customers were formed into a group for which the value of the grouping key is missing. When the query results were returned in JSON format, the `missing` key simply does not appear. Also note that the group whose key is `missing` appears first because `missing` is considered to be smaller than any other value. If some customers had had `null` as a zipcode, they would have been included in another group, appearin [...]
When an aggregation pseudo-function is used without an explicit `GROUP BY` clause, it implicitly forms the entire query block into a single group, as in Q3.22:
-##### Example
-(Q3.22) Find the average credit rating among all customers.
+##### Example
+(Q3.22) Find the average credit rating among all customers.
FROM customers AS c
SELECT AVG(c.rating) AS `avg credit rating`;
@@ -931,50 +890,42 @@ Result:
}
]
+The aggregation pseudo-function `COUNT` has a special form in which its operand is `*` instead of an expression.
+For example, `SELECT COUNT(*) FROM customers` simply returns the total number of customers, whereas `SELECT COUNT(rating) FROM customers` returns the number of customers who have known ratings (that is, their ratings are not `null` or `missing`).
-The aggregation pseudo-function `COUNT` has a special form in which its operand is `*` instead of an expression. For example, `SELECT COUNT(*) FROM customers` simply returns the total number of customers, whereas `SELECT COUNT(rating) FROM customers` returns the number of customers who have known ratings (that is, their ratings are not `null` or `missing`).
+Because the aggregation pseudo-functions sometimes restructure their operands, they can be used only in query blocks where (explicit or implicit) grouping is being done. Therefore the pseudo-functions cannot operate directly on arrays or multisets. For operating directly on JSON collections, SQL++ provides a set of ordinary functions for computing aggregations. Each ordinary aggregation function (except the ones corresponding to `COUNT` and `ARRAY_AGG`) has two versions: one that ignores [...]
-
-
- Because the aggregation pseudo-functions sometimes restructure their operands, they can be used only in query blocks where (explicit or implicit) grouping is being done. Therefore the pseudo-functions cannot operate directly on arrays or multisets. For operating directly on JSON collections, SQL++ provides a set of ordinary functions for computing aggregations. Each ordinary aggregation function (except the ones corresponding to `COUNT` and `ARRAY_AGG`) has two versions: one that ignore [...]
-
-| Aggregation pseudo-function; operates on groups only | ordinary functions: Ignores NULL or MISSING values | ordinary functions: Returns NULL if NULL or MISSING are encountered|
+| Aggregation pseudo-function; operates on groups only | Ordinary function: Ignores NULL or MISSING values | Ordinary function: Returns NULL if NULL or MISSING are encountered|
|----------|----------|--------|
|SUM| ARRAY_SUM| STRICT_SUM |
| AVG |ARRAY_MAX| STRICT_MAX |
| MAX | ARRAY_MIN| STRICT_MIN |
| MIN | ARRAY_AVG| STRICT_AVG |
-| COUNT |ARRAY_COUNT|STRICT_COUNT (see exception below) |
+| COUNT |ARRAY_COUNT|STRICT_COUNT (see exception below) |
|STDDEV_SAMP|ARRAY_STDDEV_SAMP| STRICT_STDDEV_SAMP |
|STDDEV_POP|ARRAY_STDDEV_POP| STRICT_STDDEV_POP |
|VAR_SAMP|ARRAY_VAR_SAMP| STRICT_VAR_SAMP |
|VAR_POP|ARRAY_VAR_POP| STRICT_VAR_POP |
|SKEWENESS|ARRAY_SKEWNESS| STRICT_SKEWNESS |
|KURTOSIS|ARRAY_KURTOSIS| STRICT_KURTOSIS |
-||ARRAY_AGG||||
-
-
-##### Exception: the ordinary aggregation function STRICT_COUNT operates on any collection, and returns a count of its items, including null values in the count. In this respect, STRICT_COUNT is more similar to COUNT(*) than to COUNT(expression).
+| |ARRAY_AGG| |
- Note that the ordinary aggregation functions that ignore `null` have names beginning with "ARRAY." This naming convention has historical roots. Despite their names, the functions operate on both arrays and multisets.
+Exception: the ordinary aggregation function STRICT_COUNT operates on any collection, and returns a count of its items, including null values in the count. In this respect, STRICT_COUNT is more similar to COUNT(*) than to COUNT(expression).
+Note that the ordinary aggregation functions that ignore `null` have names beginning with "ARRAY". This naming convention has historical roots. Despite their names, the functions operate on both arrays and multisets.
-
-Because of the special properties of the aggregation pseudo-functions, SQL (and therefore SQL++) is not a pure functional language. But every query that uses a pseudo-function can be expressed as an equivalent query that uses an ordinary function. Q3.23 is an example of how queries can be expressed without pseudo-functions. A more detailed explanation of all of the functions is also available [here](builtins.html#AggregateFunctions) .
+Because of the special properties of the aggregation pseudo-functions, SQL (and therefore SQL++) is not a pure functional language. But every query that uses a pseudo-function can be expressed as an equivalent query that uses an ordinary function. Q3.23 is an example of how queries can be expressed without pseudo-functions. A more detailed explanation of all of the functions is also available in the section on [Aggregate Functions](builtins.html#AggregateFunctions).
##### Example
- (Q3.23) Alternative form of Q3.22, using the ordinary function `ARRAY_AVG` rather than the aggregating pseudo-function `AVG`.
-
-
+(Q3.23) Alternative form of Q3.22, using the ordinary function `ARRAY_AVG` rather than the aggregating pseudo-function `AVG`.
SELECT ARRAY_AVG(
(SELECT VALUE c.rating
FROM customers AS c) ) AS `avg credit rating`;
- Result (same as Q3.22):
-
+Result (same as Q3.22):
[
{
@@ -984,31 +935,18 @@ Because of the special properties of the aggregation pseudo-functions, SQL (and
If the function `STRICT_AVG` had been used in Q3.23 in place of `ARRAY_AVG`, the average credit rating returned by the query would have been `null`, because at least one customer has no credit rating.
+### <a id="Group_As_clauses">GROUP AS Clause</a>
-
-### <a id="Left_outer_unnests">GROUP AS Clause</a>
-
----
-
-### GroupAsClause
-****
-
-
----
+##### GroupAsClause
+
JSON is a hierarchical format, and a fully featured JSON query language needs to be able to produce hierarchies of its own, with computed data at every level of the hierarchy. The key feature of SQL++ that makes this possible is the `GROUP AS` clause.
-
-
A query may have a `GROUP AS` clause only if it has a `GROUP BY` clause. The `GROUP BY` clause "hides" the original objects in each group, exposing only the grouping expressions and special aggregation functions on the non-grouping fields. The purpose of the `GROUP AS` clause is to make the original objects in the group visible to subsequent clauses. Thus the query can generate output data both for the group as a whole and for the individual objects inside the group.
-
-
For each group, the `GROUP AS` clause preserves all the objects in the group, just as they were before grouping, and gives a name to this preserved group. The group name can then be used in the `FROM` clause of a subquery to process and return the individual objects in the group.
-
-
-To see how this works, we'll write some queries that investigate the customers in each zipcode and their credit ratings. This would be a good time to review the sample database in Appendix 4. A part of the data is summarized below.
+To see how this works, we'll write some queries that investigate the customers in each zipcode and their credit ratings. This would be a good time to review the sample database in [Appendix 4](#Manual_data). A part of the data is summarized below.
Customers in zipcode 02115:
C35, J. Roberts, rating 565
@@ -1025,8 +963,6 @@ To see how this works, we'll write some queries that investigate the customers i
Customers with no zipcode:
C47, S. Logan, rating 625
-
-
Now let's consider the effect of the following clauses:
FROM customers AS c
@@ -1037,7 +973,6 @@ This query fragment iterates over the `customers` objects, using the iteration v
The clause `GROUP AS g` now makes the original objects visible again. For each group in turn, the variable `g` is bound to a multiset of objects, each of which has a field named `c`, which in turn contains one of the original objects. Thus after `GROUP AS g`, for the group with zipcode 02115, `g` is bound to the following multiset:
-
[
{ "c":
{ "custid": "C35",
@@ -1063,8 +998,6 @@ The clause `GROUP AS g` now makes the original objects visible again. For each g
}
]
-
-
Thus, the clauses following `GROUP AS` can see the original objects by writing subqueries that iterate over the multiset `g`.
The extra level named `c` was introduced into this multiset because the groups might have been formed from a join of two or more collections. Suppose that the `FROM` clause looked like `FROM customers AS c, orders AS o`. Then each item in the group would contain both a `customers` object and an `orders` object, and these two objects might both have a field with the same name. To avoid ambiguity, each of the original objects is wrapped in an "outer" object that gives it the name of its it [...]
@@ -1086,11 +1019,12 @@ In this case, following `GROUP AS g`, the variable `g` would be bound to the fol
...
]
-After using `GROUP AS` to make the content of a group accessible, you will probably want to write a subquery to access that content. A subquery for this purpose is written in exactly the same way as any other subquery. The name specified in the `GROUP AS` clause (`g` in the above example) is the name of a collection of objects. You can write a `FROM` clause to iterate over the objects in the collection, and you can specify an iteration variable to represent each object in turn. For `GRO [...]
+After using `GROUP AS` to make the content of a group accessible, you will probably want to write a subquery to access that content. A subquery for this purpose is written in exactly the same way as any other subquery. The name specified in the `GROUP AS` clause (`g` in the above example) is the name of a collection of objects. You can write a `FROM` clause to iterate over the objects in the collection, and you can specify an iteration variable to represent each object in turn. For `GROU [...]
Now we are ready to take a look at how `GROUP AS` might be used in a query. Suppose that we want to group customers by zipcode, and for each group we want to see the average credit rating and a list of the individual customers in the group. Here's a query that does that:
##### Example
+
(Q3.24) For each zipcode, list the average credit rating in that zipcode, followed by the customer numbers and names in numeric order.
FROM customers AS c
@@ -1157,18 +1091,16 @@ Result:
"zip": "63101"
}
]
-Note that this query contains two `ORDER BY` clauses: one in the outer query and one in the subquery. These two clauses govern the ordering of the outer-level list of zipcodes and the inner-level lists of customers, respectively. Also note that the group of customers with no zipcode comes first in the output list. For additional reading on SQL++ and more examples using `GROUP AS` as well as other clauses discussed in this manual see the [SQL++ Tutorial](https://asterixdb.apache.org/file [...]
-## <a id="Union_all">Selection and UNION ALL</a>
+Note that this query contains two `ORDER BY` clauses: one in the outer query and one in the subquery. These two clauses govern the ordering of the outer-level list of zipcodes and the inner-level lists of customers, respectively. Also note that the group of customers with no zipcode comes first in the output list.
----
-### Selection
-****
+## <a id="Union_all">Selection and UNION ALL</a>
-### UnionOption
-****
+##### Selection
+
----
+##### UnionOption
+
In a SQL++ query, two or more query blocks can be connected by the operator `UNION ALL`. The result of a `UNION ALL` between two query blocks contains all the items returned by the first query block, and all the items returned by the second query block. Duplicate items are not eliminated from the query result.
@@ -1178,87 +1110,71 @@ When two or more query blocks are connected by `UNION ALL`, they can be followed
In this example, a customer might be selected because he has ordered more than two different items (first query block) or because he has a high credit rating (second query block). By adding an explanatory string to each query block, the query writer can cause the output objects to be labeled to distinguish these two cases.
-
-
##### Example
(Q3.25a) Find customer ids for customers who have placed orders for more than two different items or who have a credit rating greater than 700, with labels to distinguish these cases.
+ FROM orders AS o, o.items AS i
+ GROUP BY o.orderno, o.custid
+ HAVING COUNT(*) > 2
+ SELECT DISTINCT o.custid AS customer_id, "Big order" AS reason
+ UNION ALL
- FROM orders AS o, o.items AS i
- GROUP BY o.orderno, o.custid
- HAVING COUNT(*) > 2
- SELECT DISTINCT o.custid AS customer_id, "Big order" AS reason
-
- UNION ALL
-
- FROM customers AS c
- WHERE rating > 700
- SELECT c.custid AS customer_id, "High rating" AS reason
- ORDER BY customer_id;
+ FROM customers AS c
+ WHERE rating > 700
+ SELECT c.custid AS customer_id, "High rating" AS reason
+ ORDER BY customer_id;
Result:
-
- [
- {
- "reason": "High rating",
- "customer_id": "C13"
- },
- {
- "reason": "Big order",
- "customer_id": "C37"
- },
- {
- "reason": "High rating",
- "customer_id": "C37"
- },
- {
- "reason": "Big order",
- "customer_id": "C41"
- }
- ]
-
-
+ [
+ {
+ "reason": "High rating",
+ "customer_id": "C13"
+ },
+ {
+ "reason": "Big order",
+ "customer_id": "C37"
+ },
+ {
+ "reason": "High rating",
+ "customer_id": "C37"
+ },
+ {
+ "reason": "Big order",
+ "customer_id": "C41"
+ }
+ ]
If, on the other hand, you simply want a list of the customer ids and you don't care to preserve the reasons, you can simplify your output by using `SELECT VALUE`, as follows:
-
-
(Q3.25b) Simplify Q3.25a to return a simple list of unlabeled customer ids.
+ FROM orders AS o, o.items AS i
+ GROUP BY o.orderno, o.custid
+ HAVING COUNT(*) > 2
+ SELECT VALUE o.custid
+ UNION ALL
- FROM orders AS o, o.items AS i
- GROUP BY o.orderno, o.custid
- HAVING COUNT(*) > 2
- SELECT VALUE o.custid
-
- UNION ALL
-
- FROM customers AS c
- WHERE rating > 700
- SELECT VALUE c.custid;
+ FROM customers AS c
+ WHERE rating > 700
+ SELECT VALUE c.custid;
Result:
- [
- "C37",
- "C41",
- "C13",
- "C37"
- ]
+ [
+ "C37",
+ "C41",
+ "C13",
+ "C37"
+ ]
## <a id="With_clauses">WITH Clause</a>
----
-
-### WithClause
-****
-
-
----
+##### WithClause
+
As in standard SQL, a `WITH` clause can be used to improve the modularity of a query. A `WITH` clause often contains a subquery that is needed to compute some result that is used later in the main query. In cases like this, you can think of the `WITH` clause as computing a “temporary view" of the input data. The next example uses a `WITH` clause to compute the total revenue of each order in 2020; then the main part of the query finds the minimum, maximum, and average revenue for orders i [...]
@@ -1274,7 +1190,7 @@ As in standard SQL, a `WITH` clause can be used to improve the modularity of a q
)
FROM order_revenue
SELECT AVG(revenue) AS average,
- MIN(revenue) AS minimum,
+ MIN(revenue) AS minimum,
MAX(revenue) AS maximum;
@@ -1292,16 +1208,14 @@ Result:
## <a id="Order_By_clauses">ORDER BY, LIMIT, and OFFSET Clauses</a>
----
-### OrderbyClause
-****
+##### OrderbyClause
+
-### LimitClause
-****
+##### LimitClause
+
-### OffsetClause
-****
----
+##### OffsetClause
+
The last three (optional) clauses to be processed in a query are `ORDER BY`, `LIMIT`, and `OFFSET`.
@@ -1317,6 +1231,7 @@ The `OFFSET` can also be used as a standalone clause, without the `LIMIT`.
The following example illustrates use of the `ORDER BY` and `LIMIT` clauses.
##### Example
+
(Q3.27) Return the top three customers by rating.
FROM customers AS c
@@ -1354,6 +1269,7 @@ The following example illustrates the use of `OFFSET`:
SELECT c.custid, c.name, c.rating
ORDER BY c.rating DESC
LIMIT 1 OFFSET 2;
+
Result:
[
@@ -1364,23 +1280,16 @@ Result:
}
]
-
-
## <a id="Subqueries">Subqueries</a>
----
-
-### Subquery
-****
-
-
----
+##### Subquery
+
A subquery is simply a query surrounded by parentheses. In SQL++, a subquery can appear anywhere that an expression can appear. Like any query, a subquery always returns a collection, even if the collection contains only a single value or is empty. If the subquery has a SELECT clause, it returns a collection of objects. If the subquery has a SELECT VALUE clause, it returns a collection of scalar values. If a single scalar value is expected, the indexing operator [0] can be used to extrac [...]
##### Example
-(Q3.29)(Subquery in SELECT clause)
+(Q3.29) (Subquery in SELECT clause)
For every order that includes item no. 120, find the order number, customer id, and customer name.
Here, the subquery is used to find a customer name, given a customer id. Since the outer query expects a scalar result, the subquery uses SELECT VALUE and is followed by the indexing operator [0].
@@ -1420,6 +1329,7 @@ Here, the subquery is used to find the average rating among all customers. Once
(FROM customers AS c2
SELECT VALUE AVG(c2.rating))[0]
SELECT c1.custid, c1.name, c1.rating;
+
Result:
[
@@ -1440,7 +1350,6 @@ Result:
}
]
-
##### Example
(Q3.31) (Subquery in FROM clause)
@@ -1454,15 +1363,15 @@ Here, the FROM clause expects to iterate over a collection of objects, so the su
SELECT o.orderno, SUM(i.qty * i.price) AS revenue
) AS r
SELECT AVG(r.revenue) AS average,
- MIN(r.revenue) AS minimum,
- MAX(r.revenue) AS maximum;
+ MIN(r.revenue) AS minimum,
+ MAX(r.revenue) AS maximum;
Result:
[
{
"average": 4669.99,
- "minimum": 130.45,
+ "minimum": 130.45,
"maximum": 18847.58
}
]
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query_title.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query_title.md
index 5a73096..d5d988a 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query_title.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/3_query_title.md
@@ -18,23 +18,3 @@
!-->
# <a id="Queries">3. Queries</a>
-
-A *query* can be an expression, or it can be constructed from blocks of code called *query blocks*. A query block may contain several clauses, including `SELECT`, `FROM`, `LET`, `WHERE`, `GROUP BY`, and `HAVING`.
-
----
-### Query
-****
-
-### Selection
-****
-
-### QueryBlock
-****
-
-### StreamGenerator
-****
-
-
----
-
-Note that, unlike SQL, SQL++ allows the `SELECT` clause to appear either at the beginning or at the end of a query block. For some queries, placing the `SELECT` clause at the end may make a query block easier to understand, because the `SELECT` clause refers to variables defined in the other clauses.
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/4_windowfunctions.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/4_windowfunctions.md
index 7a74900..d6e40e7 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/4_windowfunctions.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/4_windowfunctions.md
@@ -21,39 +21,27 @@ Window functions are special functions that compute aggregate values over a "win
A window function call is identified by an `OVER` clause, which can specify three things: partitioning, ordering, and framing. The partitioning specification is like a `GROUP BY`: it splits the input data into partitions. For example, a set of employees might be partitioned by department. The window function, when applied to a given object, is influenced only by other objects in the same partition. The ordering specification is like an `ORDER BY`: it determines the ordering of the object [...]
-
Here is an example of a window function call:
-
-
- SELECT deptno, purchase_date, item, cost,
- SUM(cost) OVER (
- PARTITION BY deptno
- ORDER BY purchase_date
- ROWS UNBOUNDED PRECEDING) AS running_total_cost
- FROM purchases
- ORDER BY deptno, purchase_date
-
-
+ SELECT deptno, purchase_date, item, cost,
+ SUM(cost) OVER (
+ PARTITION BY deptno
+ ORDER BY purchase_date
+ ROWS UNBOUNDED PRECEDING) AS running_total_cost
+ FROM purchases
+ ORDER BY deptno, purchase_date
This example partitions the `purchases` dataset by department number. Within each department, it orders the `purchases` by date and computes a running total cost for each item, using the frame specification `ROWS UNBOUNDED PRECEDING`. Note that the `ORDER BY` clause in the window function is separate and independent from the `ORDER BY` clause of the query as a whole.
-
-
-The general syntax of a window function call is specified in this section. SQL++ has a set of builtin window functions, which are listed and explained in their respective [section](builtins.html#WindowFunctions) of the builtin functions page. In addition, standard SQL aggregate functions such as `SUM` and `AVG` can be used as window functions if they are used with an `OVER` clause.
-The query language has a dedicated set of window functions.
-Aggregate functions can also be used as window functions, when they are used with an `OVER` clause.
+The general syntax of a window function call is specified in this section. SQL++ has a set of builtin window functions, which are listed and explained in the [Window Functions](builtins.html#WindowFunctions) section of the builtin functions page. In addition, standard SQL aggregate functions such as `SUM` and `AVG` can be used as window functions if they are used with an `OVER` clause.
## <a id="Window_function_call">Window Function Call</a> ##
----
-### WindowFunctionCall
-****
-
-### WindowFunctionType
-****
+##### WindowFunctionCall
+
-----
+##### WindowFunctionType
+
Refer to the [Aggregate Functions](builtins.html#AggregateFunctions) section
for a list of aggregate functions.
@@ -63,25 +51,15 @@ list of window functions.
### <a id="Window_function_arguments">Window Function Arguments</a> ###
----
-
-### WindowFunctionArguments
-****
-
-
----
+##### WindowFunctionArguments
+
Refer to the [Aggregate Functions](builtins.html#AggregateFunctions) section or the [Window Functions](builtins.html#WindowFunctions) section for details of the arguments for individual functions.
### <a id="Window_function_options">Window Function Options</a> ###
----
-
-### WindowFunctionOptions
-****
-
-
----
+##### WindowFunctionOptions
+
Window function options cannot be used with [aggregate functions](builtins.html#AggregateFunctions).
@@ -89,7 +67,7 @@ Window function options can only be used with some [window functions](builtins.h
The *FROM modifier* determines whether the computation begins at the first or last tuple in the window. It is optional and can only be used with the `nth_value()` function. If it is omitted, the default setting is `FROM FIRST`.
-The *NULLS modifier* determines whether NULL values are included in the computation, or ignored. MISSING values are treated the same way as NULL values. It is also optional and can only be used with the `first_value()`, `last_value()`, `nth_value()`, `lag()`, and `lead()` functions. If omitted, the default setting is `RESPECT NULLS`.
+The *NULLS modifier* determines whether NULL values are included in the computation, or ignored. MISSING values are treated the same way as NULL values. It is also optional and can only be used with the `first_value()`, `last_value()`, `nth_value()`, `lag()`, and `lead()` functions. If omitted, the default setting is `RESPECT NULLS`.
### <a id="Window_frame_variable">Window Frame Variable</a> ###
@@ -101,27 +79,17 @@ The `AS` keyword enables you to specify an alias for the window frame contents.
The alias is not necessary when using a [window function](builtins.html#WindowFunctions), or when using a standard SQL aggregate function with the `OVER` clause.
-
### <a id="Window_definition">Window Definition</a> ###
----
-
-### WindowDefinition
-****
-
----
+##### WindowDefinition
+
The *window definition* specifies the partitioning, ordering, and framing for window functions.
#### <a id="Window_partition_clause">Window Partition Clause</a> ####
----
-
-### WindowPartitionClause
-****
-
-
----
+##### WindowPartitionClause
+
The *window partition clause* divides the tuples into logical partitions
using one or more expressions.
@@ -134,13 +102,9 @@ This clause is optional.
If omitted, all tuples are united in a single partition.
#### <a id="Window_order_clause">Window Order Clause</a> ####
----
-### WindowOrderClause
-****
-
-
----
+##### WindowOrderClause
+
The *window order clause* determines how tuples are ordered within each partition. The window function works on tuples in the order specified by this clause.
@@ -159,23 +123,19 @@ This clause is optional. If omitted, all tuples are considered peers, i.e. their
If the window frame is defined by `RANGE` or `GROUPS`, the results are same
for each tuple.
-##### Note #####
-
-This clause does not guarantee the overall order of the query results. To guarantee the order of the final results, use the query `ORDER BY` clause.
-
+**Note:** This clause does not guarantee the overall order of the query results. To guarantee the order of the final results, use the query `ORDER BY` clause.
#### <a id="Window_frame_clause">Window Frame Clause</a> ####
-### WindowFrameClause
-****
+##### WindowFrameClause
+
-
-The *window frame clause* defines the window frame. It can be used with all [aggregate functions](builtins.html#AggregateFunctions) and some [window functions](builtins.html#WindowFunctions) - refer to the descriptions of individual functions for more details. It is optional and allowed only when the [window order clause](#Window_order_clause) is present.
+The *window frame clause* defines the window frame. It can be used with all [aggregate functions](builtins.html#AggregateFunctions) and some [window functions](builtins.html#WindowFunctions) — refer to the descriptions of individual functions for more details. It is optional and allowed only when the [window order clause](#Window_order_clause) is present.
* If this clause is omitted and there is no [window order clause](#Window_order_clause), the window frame is the entire partition.
* If this clause is omitted but there is a [window order clause](#Window_order_clause), the window frame becomes all tuples
- in the partition preceding the current tuple and its peers - the same as `RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW`.
+ in the partition preceding the current tuple and its peers — the same as `RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW`.
The window frame can be defined in the following ways:
@@ -185,29 +145,18 @@ The window frame can be defined in the following ways:
* `GROUPS`: Counts all groups of tied rows within the frame. The function produces deterministic results.
-##### Note #####
-
-If this clause uses `RANGE` with either *Expr* `PRECEDING` or *Expr* ` FOLLOWING`, the [window order clause](#Window_order_clause) must have only a single ordering term.
-
+**Note:** If this clause uses `RANGE` with either *Expr* `PRECEDING` or *Expr* `FOLLOWING`, the [window order clause](#Window_order_clause) must have only a single ordering term.
The ordering term expression must evaluate to a number.
-
If these conditions are not met, the window frame will be empty, which means the window function will return its default value: in most cases this is `null`, except for `strict_count()` or `array_count()`, whose default value is 0. This restriction does not apply when the window frame uses `ROWS` or `GROUPS`.
-##### Tip #####
-
-The `RANGE` window frame is commonly used to define window frames based
+**Tip:** The `RANGE` window frame is commonly used to define window frames based
on date or time.
-
If you want to use `RANGE` with either *Expr* `PRECEDING` or *Expr* `FOLLOWING`, and you want to use an ordering expression based on date or time, the expression in *Expr* `PRECEDING` or *Expr* `FOLLOWING` must use a data type that can be added to the ordering expression.
#### <a id="Window_frame_extent">Window Frame Extent</a> ####
----
-
-### WindowFrameExtent
-****
-
----
+##### WindowFrameExtent
+
The *window frame extent clause* specifies the start point and end point of the window frame.
The expression before `AND` is the start point and the expression after `AND` is the end point.
@@ -226,13 +175,13 @@ Window frame extents that result in an explicit violation are:
Window frame extents that result in an implicit violation are:
-* `BETWEEN UNBOUNDED PRECEDING AND` *Expr* `PRECEDING` - if *Expr* is too high, some tuples may generate an empty window frame.
+* `BETWEEN UNBOUNDED PRECEDING AND` *Expr* `PRECEDING` — if *Expr* is too high, some tuples may generate an empty window frame.
-* `BETWEEN` *Expr* `PRECEDING AND` *Expr* `PRECEDING` - if the second *Expr* is greater than or equal to the first *Expr*, all result sets will generate an empty window frame.
+* `BETWEEN` *Expr* `PRECEDING AND` *Expr* `PRECEDING` — if the second *Expr* is greater than or equal to the first *Expr*, all result sets will generate an empty window frame.
-* `BETWEEN` *Expr* `FOLLOWING AND` *Expr* `FOLLOWING` - if the first *Expr* is greater than or equal to the second *Expr*, all result sets will generate an empty window frame.
+* `BETWEEN` *Expr* `FOLLOWING AND` *Expr* `FOLLOWING` — if the first *Expr* is greater than or equal to the second *Expr*, all result sets will generate an empty window frame.
-* `BETWEEN` *Expr* `FOLLOWING AND UNBOUNDED FOLLOWING` - if *Expr* is too high, some tuples may generate an empty window frame.
+* `BETWEEN` *Expr* `FOLLOWING AND UNBOUNDED FOLLOWING` — if *Expr* is too high, some tuples may generate an empty window frame.
* If the [window frame exclusion clause](#Window_frame_exclusion) is present, any window frame specification may result in empty window frame.
@@ -240,21 +189,16 @@ The *Expr* must be a positive constant or an expression that evaluates as a posi
#### <a id="Window_frame_exclusion">Window Frame Exclusion</a> ####
----
-
-### WindowFrameExclusion
-****
-
-
----
+##### WindowFrameExclusion
+
The *window frame exclusion clause* enables you to exclude specified tuples from the window frame.
-This clause can be used with all [aggregate functions](builtins.html#AggregateFunctions) and some [window functions](builtins.html#WindowFunctions) - refer to the descriptions of individual functions for more details.
+This clause can be used with all [aggregate functions](builtins.html#AggregateFunctions) and some [window functions](builtins.html#WindowFunctions) — refer to the descriptions of individual functions for more details.
This clause is allowed only when the [window frame clause](#Window_frame_clause) is present.
-This clause is optional. If this clause is omitted, the default is no exclusion - the same as `EXCLUDE NO OTHERS`.
+This clause is optional. If this clause is omitted, the default is no exclusion — the same as `EXCLUDE NO OTHERS`.
* `EXCLUDE CURRENT ROW`: If the current tuple is still part of the window frame, it is removed from the window frame.
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/7_ddl_dml.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/7_ddl_dml.md
index 222c7a4..e064f06 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/7_ddl_dml.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/7_ddl_dml.md
@@ -20,22 +20,19 @@
## <a id="Lifecycle_management_statements">Lifecycle Management Statements</a>
### <a id="Use">Use Statement</a>
----
-### UseStmnt
-****
+##### UseStmnt
+
-### DataverseName
-****
-
----
+##### DataverseName
+
At the uppermost level, the world of data is organized into data namespaces called **dataverses**.
To set the default dataverse for statements, the `USE` statement is provided.
As an example, the following statement sets the default dataverse to be `Commerce`.
- USE Commerce;
+ USE Commerce;
### <a id="Sets"> Set Statement</a>
@@ -50,24 +47,21 @@ In general, the function body (expression) can be any legal query expression.
The function named in the `DECLARE FUNCTION` statement is accessible only in the current query. To create a persistent function for use in multiple queries, use the `CREATE FUNCTION` statement.
----
-### FunctionDeclaration
-****
-
----
+##### FunctionDeclaration
+
The following is a simple example of a temporary function definition and its use.
##### Example
DECLARE FUNCTION nameSearch(customerId){
- (SELECT c.custid, c.name
- FROM customers AS c
- WHERE c.custid = customerId)[0]
+ (SELECT c.custid, c.name
+ FROM customers AS c
+ WHERE c.custid = customerId)[0]
};
- SELECT VALUE nameSearch("C25");
+ SELECT VALUE nameSearch("C25");
For our sample data set, this returns:
@@ -76,31 +70,26 @@ For our sample data set, this returns:
]
### <a id="Create"> Create Statement</a>
----
-### CreateStmnt
-****
-### DataverseName
-****
+##### CreateStmnt
+
-### QualifiedName
-****
+##### DataverseName
+
-### DoubleQualifiedName
-****
+##### QualifiedName
+
----
+##### DoubleQualifiedName
+
The `CREATE` statement is used for creating dataverses as well as other persistent artifacts in a dataverse.
It can be used to create new dataverses, datatypes, datasets, indexes, and user-defined query functions.
#### <a id="Dataverses"> Create Dataverse</a>
----
-### CreateDataverse
-****
-
----
+##### CreateDataverse
+
The `CREATE DATAVERSE` statement is used to create new dataverses.
To ease the authoring of reusable query scripts, an optional `IF NOT EXISTS` clause is included to allow
@@ -115,29 +104,26 @@ The following example creates a new dataverse named `Commerce` if one does not a
#### <a id="Types"> Create Type </a>
----
-### CreateType
-****
-
-### ObjectTypeDef
-****
+##### CreateType
+
-### ObjectField
-****
+##### ObjectTypeDef
+
-### TypeExpr
-****
+##### ObjectField
+
-### ArrayTypeDef
-****
+##### TypeExpr
+
-### MultisetTypeDef
-****
+##### ArrayTypeDef
+
-### TypeReference
-****
+##### MultisetTypeDef
+
----
+##### TypeReference
+
The `CREATE TYPE` statement is used to create a new named datatype.
This type can then be used to create stored collections or utilized when defining one or more other datatypes.
@@ -147,38 +133,38 @@ A object type can be defined as being either open or closed.
Instances of a closed object type are not permitted to contain fields other than those specified in the create type statement.
Instances of an open object type may carry additional fields, and open is the default for new types if neither option is specified.
-The following example creates three new object type called `addressType` , `customerType` and `itemType`.
+The following example creates three new object types called `addressType`, `customerType`, and `itemType`.
Their fields are essentially traditional typed name/value pairs (much like SQL fields).
Since it is defined as (defaulting to) being an open type, instances will be permitted to contain more than what is specified in the type definition. Indeed many of the customer objects contain a rating as well, however this is not necessary for the customer object to be created. As can be seen in the sample data, customers can exist without ratings or with part (or all) of the address missing.
##### Example
- CREATE TYPE addressType AS {
- street: string,
- city: string,
- zipcode: string?
- };
+ CREATE TYPE addressType AS {
+ street: string,
+ city: string,
+ zipcode: string?
+ };
CREATE TYPE customerType AS {
- custid: string,
- name: string,
- address: addressType?
+ custid: string,
+ name: string,
+ address: addressType?
};
- CREATE TYPE itemType AS {
- itemno: int,
- qty: int,
- price: int
- };
+ CREATE TYPE itemType AS {
+ itemno: int,
+ qty: int,
+ price: int
+ };
Optionally, you may wish to create a type that has an automatically generated primary key field. The example below shows an alternate form of `itemType` which achieves this by setting its primary key, `itemno`, to UUID. (Refer to the Datasets section later for more details on such fields.)
##### Example
- CREATE TYPE itemType AS {
- itemno: uuid,
- qty: int,
- price: int
- };
+ CREATE TYPE itemType AS {
+ itemno: uuid,
+ qty: int,
+ price: int
+ };
Note that the type of the `itemno` in this example is UUID. This field type can be used if you want to have an autogenerated-PK field. (Refer to the Datasets section later for more details on such fields.)
@@ -188,54 +174,51 @@ although the `ship_date` field is marked as optional and may thus be `NULL` or `
##### Example
- CREATE TYPE orderType AS CLOSED {
- orderno: int,
- custid: string,
- order_date: string,
- ship_date: string?,
- items: [ itemType ]
- };
+ CREATE TYPE orderType AS CLOSED {
+ orderno: int,
+ custid: string,
+ order_date: string,
+ ship_date: string?,
+ items: [ itemType ]
+ };
#### <a id="Datasets"> Create Dataset</a>
----
-### CreateDataset
-****
+##### CreateDataset
+
-### CreateInternalDataset
-****
+##### CreateInternalDataset
+
-### CreateExternalDataset
-****
+##### CreateExternalDataset
+
-### DatasetTypeDef
-****
+##### DatasetTypeDef
+
-### DatasetFieldDef
-****
+##### DatasetFieldDef
+
-### TypeReference
-****
+##### TypeReference
+
-### PrimaryKey
-****
+##### PrimaryKey
+
-### NestedField
-****
+##### NestedField
+
-### AdapterName
-****
+##### AdapterName
+
-### Configuration
-****
+##### Configuration
+
-### KeyValuePair
-****
+##### KeyValuePair
+
-### Properties
-****
-
----
+##### Properties
+
The `CREATE DATASET` statement is used to create a new dataset.
Datasets are named, multisets of object type instances;
@@ -277,7 +260,7 @@ When defining an External dataset, an appropriate adapter type must be selected
The following example creates an Internal dataset for storing `customerType` objects.
It specifies that their `custid` field is their primary key.
-#### Example
+##### Example
CREATE INTERNAL DATASET customers(customerType) PRIMARY KEY custid;
@@ -286,13 +269,13 @@ It also specifies that the `itemno` field is an auto-generated field, meaning th
Note that the `itemno` field's declared type must be UUID in this case.
-#### Example
+##### Example
CREATE DATASET MyItems(itemType) PRIMARY KEY itemno AUTOGENERATED;
Alternatively the dataset object type can be specified using inline type definition syntax.
-#### Example
+##### Example
CREATE DATASET MyItems(itemno INT NOT UNKNOWN, qty INT NOT UNKNOWN, price INT NOT UNKNOWN) PRIMARY KEY itemno AUTOGENERATED;
@@ -301,7 +284,7 @@ The choice of the `hdfs` adapter means that this dataset's data actually resides
The example `CREATE` statement also provides parameters used by the hdfs adapter:
the URL and path needed to locate the data in HDFS and a description of the data format.
-#### Example
+##### Example
CREATE EXTERNAL DATASET LineItem(LineItemType) USING hdfs (
("hdfs"="hdfs://HOST:PORT"),
@@ -312,26 +295,23 @@ the URL and path needed to locate the data in HDFS and a description of the data
#### <a id="Indices">Create Index</a>
----
-### CreateIndex
-****
-
-### CreateSecondaryIndex
-****
+##### CreateIndex
+
-### CreatePrimaryKeyIndex
-****
+##### CreateSecondaryIndex
+
-### IndexField
-****
+##### CreatePrimaryKeyIndex
+
-### NestedField
-****
+##### IndexField
+
-### IndexType
-****
+##### NestedField
+
----
+##### IndexType
+
The `CREATE INDEX` statement creates a secondary index on one or more fields of a specified dataset.
Supported index types include `BTREE` for totally ordered datatypes, `RTREE` for spatial data,
@@ -345,9 +325,9 @@ specified at the end of the index definition.
(if the optional field exists in the object) always matches this specified (open) field type.
The following example creates a btree index called `cCustIdx` on the `custid` field of the orders dataset.
-This index can be useful for accelerating exact-match queries, range search queries, and joins involving the `custid`field.
+This index can be useful for accelerating exact-match queries, range search queries, and joins involving the `custid` field.
-#### Example
+##### Example
CREATE INDEX cCustIdx ON orders(custid) TYPE BTREE;
@@ -356,7 +336,7 @@ This index can be useful for accelerating exact-match queries, range search quer
The index is enforced so that records that do not have the `createdTime` field or have a mismatched type on the field
cannot be inserted into the dataset.
-#### Example
+##### Example
CREATE INDEX oCreatedTimeIdx ON orders(createdTime: datetime?) TYPE BTREE ENFORCED;
@@ -367,7 +347,7 @@ and joins involving the `addedTime` field.
The index is not enforced so that records that do not have the `addedTime` field or have a mismatched type on the field
can still be inserted into the dataset.
-#### Example
+##### Example
CREATE INDEX cAddedTimeIdx ON customers(addedTime: datetime?);
@@ -377,25 +357,25 @@ This index can be useful for accelerating exact-match queries, range search quer
and joins involving the nested `orderUserName` field.
Such nested fields must be singular, i.e., one cannot index through (or on) an array-valued field.
-#### Example
+##### Example
CREATE INDEX oOrderUserNameIdx ON orders(order.orderUserName) TYPE BTREE;
The following example creates an open rtree index called `oOrderLocIdx` on the order-location field of the `orders` dataset. This index can be useful for accelerating queries that use the [`spatial-intersect` function](builtins.html#spatial_intersect) in a predicate involving the sender-location field.
-#### Example
+##### Example
CREATE INDEX oOrderLocIDx ON orders(`order-location` : point?) TYPE RTREE ENFORCED;
The following example creates a 3-gram index called `cUserIdx` on the name field of the `customers` dataset. This index can be used to accelerate some similarity or substring maching queries on the name field. For details refer to the document on [similarity queries](similarity.html#NGram_Index).
-#### Example
+##### Example
CREATE INDEX cUserIdx ON customers(name) TYPE NGRAM(3);
The following example creates a keyword index called `oCityIdx` on the `city` within the `address` field of the `customers` dataset. This keyword index can be used to optimize queries with token-based similarity predicates on the `address` field. For details refer to the document on [similarity queries](similarity.html#Keyword_Index).
-#### Example
+##### Example
CREATE INDEX oCityIdx ON customers(address.city) TYPE KEYWORD;
@@ -404,7 +384,7 @@ This index is useful for speeding up aggregation queries which involve only prim
The name of the index is optional. If the name is not specified, the system will generate
one. When the user would like to drop this index, the metadata can be queried to find the system-generated name.
-#### Example
+##### Example
CREATE PRIMARY INDEX cus_pk_idx ON customers;
@@ -420,32 +400,32 @@ To look up the the above primary-key index, issue the following query:
The query returns:
- [
- {
- "DataverseName": "Commerce",
- "DatasetName": "customers",
- "IndexName": "cus_pk_idx",
- "IndexStructure": "BTREE",
- "SearchKey": [],
- "IsPrimary": false,
- "Timestamp": "Fri Sep 18 14:15:51 PDT 2020",
- "PendingOp": 0
- },
- {
- "DataverseName": "Commerce",
- "DatasetName": "customers",
- "IndexName": "customers",
- "IndexStructure": "BTREE",
- "SearchKey": [
- [
- "custid"
- ]
- ],
- "IsPrimary": true,
- "Timestamp": "Thu Jul 16 13:07:37 PDT 2020",
- "PendingOp": 0
- }
- ]
+ [
+ {
+ "DataverseName": "Commerce",
+ "DatasetName": "customers",
+ "IndexName": "cus_pk_idx",
+ "IndexStructure": "BTREE",
+ "SearchKey": [],
+ "IsPrimary": false,
+ "Timestamp": "Fri Sep 18 14:15:51 PDT 2020",
+ "PendingOp": 0
+ },
+ {
+ "DataverseName": "Commerce",
+ "DatasetName": "customers",
+ "IndexName": "customers",
+ "IndexStructure": "BTREE",
+ "SearchKey": [
+ [
+ "custid"
+ ]
+ ],
+ "IsPrimary": true,
+ "Timestamp": "Thu Jul 16 13:07:37 PDT 2020",
+ "PendingOp": 0
+ }
+ ]
Remember that `CREATE PRIMARY INDEX` creates a secondary index.
That is the reason the `IsPrimary` field is false.
@@ -453,11 +433,8 @@ The primary-key index can be identified by the fact that the `SearchKey` field i
#### <a id="Synonyms"> Create Synonym</a>
----
-### CreateSynonym
-****
-
----
+##### CreateSynonym
+
The `CREATE SYNONYM` statement creates a synonym for a given dataset.
This synonym may be used used instead of the dataset name in `SELECT`, `INSERT`, `UPSERT`, `DELETE`, and `LOAD` statements.
@@ -471,24 +448,21 @@ The target dataset does not need to exist when the synonym is created.
SELECT * FROM customersSynonym;
-More information on how synonyms are resolved can be found in the [Appendix 3. Variable Bindings and Name Resolution](#Variable_bindings_and_name_resolution).
+More information on how synonyms are resolved can be found in [Appendix 3. Variable Bindings and Name Resolution](#Variable_bindings_and_name_resolution).
#### <a id="Create_function">Create Function</a>
The `CREATE FUNCTION` statement creates a **named** function that can then be used and reused in queries.
The body of a function can be any query expression involving the function's parameters.
----
-### CreateFunction
-****
-
-### FunctionParameters
-****
+##### CreateFunction
+
-### ExternalFunctionDef
-****
+##### FunctionParameters
+
----
+##### ExternalFunctionDef
+
The following is an example of a `CREATE FUNCTION` statement which is similar to our earlier `DECLARE FUNCTION` example.
@@ -531,26 +505,23 @@ would be as follows
### <a id="Removal">Drop Statement</a>
----
-### DropStmnt
-****
+##### DropStmnt
+
-### DataverseName
-****
+##### DataverseName
+
-### QualifiedName
-****
+##### QualifiedName
+
-### DoubleQualifiedName
-****
+##### DoubleQualifiedName
+
-### FunctionSignature
-****
+##### FunctionSignature
+
-### FunctionParameters
-****
-
----
+##### FunctionParameters
+
The `DROP` statement is the inverse of the `CREATE` statement. It can be used to drop dataverses, datatypes, datasets, indexes, functions, and synonyms.
@@ -580,20 +551,17 @@ the identifying name of the function to be dropped must explicitly include that
### <a id="Load_statement">Load Statement</a>
----
-### LoadStmnt
-****
-
-### AdapterName
-****
+##### LoadStmnt
+
-### Configuration
-****
+##### AdapterName
+
-### KeyValuePair
-****
+##### Configuration
+
----
+##### KeyValuePair
+
The `LOAD` statement is used to initially populate a dataset via bulk loading of data from an external file.
An appropriate adapter must be selected to handle the nature of the desired external data.
@@ -614,11 +582,8 @@ The following example shows how to bulk load the `customers` dataset from an ext
### <a id="Inserts">Insert Statement</a>
----
-### InsertStmnt
-****
-
----
+##### InsertStmnt
+
The `INSERT` statement is used to insert new data into a dataset.
The data to be inserted comes from a query expression.
@@ -644,11 +609,8 @@ The following example illustrates a query-based insertion.
### <a id="Upserts">Upsert Statement</a>
----
-### UpsertStmnt
-****
-
----
+##### UpsertStmnt
+
The `UPSERT` statement syntactically mirrors the `INSERT `statement discussed above.
The difference lies in its semantics, which for `UPSERT` are "add or replace" instead of the `INSERT` "add if not present, else error" semantics.
@@ -667,11 +629,8 @@ The following example illustrates a query-based upsert operation.
### <a id="Deletes">Delete Statement</a>
----
-### DeleteStmnt
-****
-
----
+##### DeleteStmnt
+
The `DELETE` statement is used to delete data from a target dataset.
The data to be deleted is identified by a boolean expression involving the variable bound to the target dataset in the `DELETE` statement.
@@ -692,3 +651,4 @@ The following examples illustrate single-object deletions.
##### Example
DELETE FROM customers WHERE custid = "C47";
+
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/7_ddl_head.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/7_ddl_head.md
index 39a5439..b73d82d 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/7_ddl_head.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/7_ddl_head.md
@@ -19,15 +19,11 @@
# <a id="DDL_and_DML_statements">7. DDL and DML statements</a>
----
+##### Stmnt
+
-### Stmnt
-****
-
-### SingleStmnt
-****
-
----
+##### SingleStmnt
+
In addition to queries, an implementation of SQL++ needs to support statements for data definition
and manipulation purposes as well as controlling the context to be used in evaluating query expressions.
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_2_parameters.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_2_parameters.md
index 86510cf..2799acc 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_2_parameters.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_2_parameters.md
@@ -19,8 +19,8 @@
The `SET` statement can be used to override some cluster-wide configuration parameters for a specific request:
-### SetStmnt
-****
+##### SetStmnt
+
As parameter identifiers are qualified names (containing a '.') they have to be escaped using backticks (\`\`).
Note that changing query parameters will not affect query correctness but only impact performance
@@ -32,7 +32,7 @@ in a cluster. A user can manually specify the maximum execution parallelism for
using the following parameter:
* **compiler.parallelism**: the maximum number of CPU cores can be used to process a query.
-There are three cases of the value *p* for compiler.parallelism:
+ There are three cases of the value *p* for compiler.parallelism:
- *p* \< 0 or *p* \> the total number of cores in a cluster: the system will use all available cores in the
cluster;
@@ -51,6 +51,7 @@ There are three cases of the value *p* for compiler.parallelism:
FROM customers c JOIN orders o ON c.custid = o.custid;
## <a id="Memory_parameters">Memory Parameters</a>
+
In the system, each blocking runtime operator such as join, group-by and order-by
works within a fixed memory budget, and can gracefully spill to disks if
the memory budget is smaller than the amount of data they have to hold.
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_3_resolution.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_3_resolution.md
index c3f0450..a4acbb0 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_3_resolution.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_3_resolution.md
@@ -197,16 +197,15 @@ The likely intent of the query above can be accomplished as follows:
SELECT e.name, pay
ORDER BY pay
-Note:
-In the phrase *expr1* `JOIN` *expr2* `ON` *expr3*, variables defined in *expr1* are visible in *expr3* but not in *expr2*. Here's an example that will not work:
+Note that in the phrase *expr1* `JOIN` *expr2* `ON` *expr3*, variables defined in *expr1* are visible in *expr3* but not in *expr2*. Here's an example that will not work:
- FROM orders AS o JOIN o.items AS i ON 1 = 1
+ FROM orders AS o JOIN o.items AS i ON 1 = 1
The variable `o`, defined in the phrase before `JOIN`, cannot be used in the phrase immediately following `JOIN`. The probable intent of this example could be accomplished in either of the following ways:
- FROM orders AS o UNNEST o.items AS i
+ FROM orders AS o UNNEST o.items AS i
- FROM orders AS o, o.items AS i
+ FROM orders AS o, o.items AS i
To summarize this rule: You may not use left-correlation in an explicit `JOIN` clause.
@@ -281,3 +280,4 @@ The rules for resolving the leftmost identifier are:
5. Once the leftmost identifier has been resolved, the following dots and identifiers in the name (if any) are treated as a path expression that navigates to a field nested inside that object.
The name resolves to the field at the end of the path.
If this field does not exist, the value `missing` is returned.
+
diff --git a/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_4_manual_data.md b/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_4_manual_data.md
index 7516e3f..a07c67b 100644
--- a/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_4_manual_data.md
+++ b/asterixdb/asterix-doc/src/main/markdown/sqlpp/appendix_4_manual_data.md
@@ -292,3 +292,4 @@ This appendix lists the data definitions and the datasets used for the examples
"items": []
}
]
+