OpenText Analytics Database 26.2.x – Language elements

Sql-Reference: Keywords

Mon, 01 Jan 0001 00:00:00 +0000

Keywords are words that have a specific meaning in the SQL language. Every SQL statement contains one or more keywords. Although SQL is not case-sensitive with respect to keywords, they are generally shown in uppercase letters throughout this documentation for readability purposes.

Note

If you use a keyword as the name of an identifier or an alias in your SQL statements, you may have to qualify the keyword with AS or double-quotes. OpenText™ Analytics Database requires AS or double-quotes for certain reserved and non-reserved words to prevent confusion with expression syntax, or where the use of a word would be ambiguous.

Reserved words and keywords

Many keywords are also reserved words.

OpenText recommends that you do not use reserved words as names for objects or as identifiers, as including reserved words can make your SQL statements confusing. Reserved words that are used as names for objects or identifiers must be enclosed in double-quotes.

Note

All reserved words are also keywords, but the database can add reserved words that are not keywords. A reserved word can simply be a word that is reserved for future use.

Non-reserved keywords

Non-reserved keywords have a special meaning in some contexts, but can be used as identifiers in others. You can use non-reserved keywords as aliases—for example, SOURCE:

=> SELECT my_node AS SOURCE FROM nodes;

Note

The database uses several non-reserved keywords in directed queries to specify special join types. You can use these keywords as table aliases only if they are double-quoted; otherwise, double-quotes can be omitted:

ANTI
NULLAWARE
SEMI
SEMIALL
UNI

Viewing the list of reserved and non-reserved keywords

To view the current list of reserved and non-reserved words, query system table KEYWORDS. The database lists keywords alphabetically and identifies them as reserved (R) or non-reserved (N).

For example, the following query returns all reserved keywords that begin with the letter B:

=> SELECT * FROM keywords WHERE reserved = 'R' AND keyword ilike 'B%';
 keyword | reserved
---------+----------
 BETWEEN | R
 BIGINT  | R
 BINARY  | R
 BIT     | R
 BOOLEAN | R
 BOTH    | R
(6 rows)

Sql-Reference: Identifiers

Mon, 01 Jan 0001 00:00:00 +0000

Identifiers (names) of objects such as schema, table, projection, column names, and so on, can be up to 128 bytes in length.

Unquoted identifiers

Unquoted SQL identifiers must begin with one of the following:

Non-Unicode letters: A–Z or a-z
Underscore (_)

Subsequent characters in an identifier can be any combination of the following:

Non-Unicode letters: A–Z or a-z
Underscore (_)
Digits(0–9)
Unicode letters (letters with diacriticals or not in the Latin alphabet), unsupported for model names
Dollar sign ($), unsupported for model names

Caution
The SQL standard does not support dollar sign in identifiers, so usage can cause application portability problems.

Quoted identifiers

Note

Quoted identifiers are not supported for model names.

Identifiers enclosed in double quote (") characters can contain any character. If you want to include a double quote, you need a pair of them; for example """". You can use names that would otherwise be invalid—for example, names that include only numeric characters ("123") or contain space characters, punctuation marks, and SQL or reserved keywords. For example:

CREATE SEQUENCE "my sequence!";

Double quotes are required for non-alphanumerics and SQL keywords such as "1time", "Next week" and "Select".

Case sensitivity

Identifiers are not case-sensitive. Thus, identifiers "ABC", "ABc", and "aBc" are synonymous, as are ABC, ABc, and aBc.

Non-ASCII characters

OpenText™ Analytics Database accepts non-ASCII UTF-8 Unicode characters for table names, column names, and other identifiers, extending the cases where upper/lower case distinctions are ignored (case-folded) to all alphabets, including Latin, Cyrillic, and Greek.

For example, the following CREATE TABLE statement uses the ß (German eszett) in the table name:

=> CREATE TABLE straße(x int, y int);
   CREATE TABLE

Identifiers are stored as created

SQL identifiers, such as table and column names, are not converted to lowercase. They are stored as created, and references to them are resolved using case-insensitive compares. For example, the following statement creates table ALLCAPS.

=> CREATE TABLE ALLCAPS(c1 varchar(30));
=> INSERT INTO ALLCAPS values('upper case');

The following statements are variations of the same query:

=> SELECT * FROM ALLCAPS;
=> SELECT * FROM allcaps;
=> SELECT * FROM "allcaps";

The three queries all return the same result:

     c1
------------
 upper case
(1 row)

Note that the database returns an error if you try to create the table AllCaps:

=> CREATE TABLE AllCaps(c1 varchar(30));
   ROLLBACK:  table "AllCaps" already exists

See QUOTE_IDENT for additional information.

Sql-Reference: Literals

Mon, 01 Jan 0001 00:00:00 +0000

Literals are numbers or strings used in SQL as constants. Literals are included in the select-list, along with expressions and built-in functions and can also be constants.

OpenText™ Analytics Database provides support for number-type literals (integers and numerics), string literals, VARBINARY string literals, and date/time literals. The various string literal formats are discussed in this section.

Sql-Reference: Operators

Mon, 01 Jan 0001 00:00:00 +0000

Operators are logical, mathematical, and equality symbols used in SQL to evaluate, compare, or calculate values.

Sql-Reference: Expressions

Mon, 01 Jan 0001 00:00:00 +0000

SQL expressions are the components of a query that compare a value or values against other values. They can also perform calculations. An expression found inside a SQL statement is usually in the form of a conditional statement.

Some functions also use Lambda functions.

Operator precedence

The following table shows operator precedence in decreasing (high to low) order.

When an expression includes more than one operator, specify the order of operation using parentheses, rather than relying on operator precedence.

Operator/Element	Associativity	Description
`.`	left	table/column name separator
`::`	left	typecast
`[ ]`	left	array element selection
`-`	right	unary minus
`^`	left	exponentiation
`* / %`	left	multiplication, division, modulo
`+ -`	left	addition, subtraction
`IS`		IS TRUE, IS FALSE, IS UNKNOWN, IS NULL
`IN`		set membership
`BETWEEN`		range containment
`OVERLAPS`		time interval overlap
`LIKE`		string pattern matching
`< >`		less than, greater than
`=`	right	equality, assignment
`NOT`	right	logical negation
`AND`	left	logical conjunction
`OR`	left	logical disjunction

Expression evaluation rules

The order of evaluation of subexpressions is not defined. In particular, the inputs of an operator or function are not necessarily evaluated left-to-right or in any other fixed order. To force evaluation in a specific order, use a CASE construct. For example, the following is an untrustworthy way of trying to avoid division by zero in a WHERE clause:

=> SELECT x, y WHERE x <> 0 AND y/x > 1.5; --- unsafe

The following example, however, is safe:

=> SELECT x, y
   WHERE
     CASE
       WHEN x <> 0 THEN y/x > 1.5
       ELSE false
     END;

A CASE construct used in this fashion defeats optimization attempts, so use it only when necessary. In this particular example, it would be best to avoid the issue by writing y > 1.5*x instead.

Limits to SQL expressions

Expressions are limited by the available stack. OpenText™ Analytics Database requires at least 100KB of free stack. If this limit is exceeded then the error "The query contains an expression that is too complex to analyze" can be returned. Adding physical memory and/or increasing the value of ulimit -s can increase the available stack and prevent the error.

Analytic expressions have a maximum recursion depth of 2000. If this limit is exceeded, the error "The query contains an expression that is too complex to analyze" can be returned. The recursion depth limit cannot be increased.

Sql-Reference: Lambda functions

Mon, 01 Jan 0001 00:00:00 +0000

Some SQL functions have arguments that are lambda functions. A lambda function is an unnamed inline function that is evaluated by the containing SQL function and returns a value.

Syntax

Lambda with one argument:

argument -> expression

Lambda with more than one argument:

(argument, ...) -> expression

Arguments

`argument`	Name to use for an input value for the expression. The name cannot be a reserved keyword, the name of an argument to a parent or nested lambda, or a column name or alias.
`expression`	Expression that uses the input arguments and returns a result to the containing SQL function. See the documentation of individual SQL functions for restrictions on return values. For example, some functions require a Boolean result.

Examples

The ARRAY_FIND function returns the first index that matches the element being searched for. Instead of a literal element, you can write a lambda function that returns a Boolean. The lambda function is applied to each element in the array until a match is found or all elements have been tested. In the following example, each person in the table has an array of email addresses, and the function locates fake addresses:

=> CREATE TABLE people (id INT, name VARCHAR, email ARRAY[VARCHAR,5]);

=> SELECT name, ARRAY_FIND(email, e -> REGEXP_LIKE(e,'example.com','i'))
   AS 'example.com'
   FROM people;
     name      | example.com
---------------+-------------
 Alice Adams   |           1
 Bob Adams     |           1
 Carol Collins |           0
 Dave Jones    |           0
(4 rows)

The argument e represents the individual element, and the body of the lambda expression is the regular-expression comparison. The input table has four rows; in each row, the lambda function is called once per array element.

In the following example, a schedules table includes an array of events, where each event is a ROW with several fields:

=> CREATE TABLE schedules
       (guest VARCHAR,
       events ARRAY[ROW(e_date DATE, e_name VARCHAR, price NUMERIC(8,2))]);

You can use the CONTAINS function with a lambda expression to find people who have more than one event on the same day. The second argument, idx, is the index of the current element:

=> SELECT guest FROM schedules
WHERE CONTAINS(events, (e, idx) ->
                       (idx < ARRAY_LENGTH(events) - 1)
                       AND (e.e_date = events[idx + 1].e_date));
    guest
-------------
 Alice Adams
(1 row)

Sql-Reference: Predicates

Mon, 01 Jan 0001 00:00:00 +0000

Predicates are truth-tests. If the predicate test is true, it returns a value. Each predicate is evaluated per row, so that when the predicate is part of an entire table SELECT statement, the statement can return multiple results.

Predicates consist of a set of parameters and arguments. For example, in the following WHERE clause:

WHERE name = 'Smith'

name = 'Smith' is the predicate
'Smith' is an expression

Sql-Reference: Hints

Mon, 01 Jan 0001 00:00:00 +0000

Hints are directives that you embed within a query or directed query. They conform to the following syntax:

/*+hint-name[, hint-name]...*/

Hints are bracketed by comment characters /*+ and */, which can enclose multiple comma-delimited hints. For example:

SELECT /*+syntactic_join,verbatim*/

Restrictions

When embedding hints in a query, be aware of the following restrictions:

Do not embed spaces in the comment characters /* and */.
In general, spaces are allowed before and after the plus (+) character and hint-name; however, some third-party tools do not support spaces embedded inside /*+.

Supported hints

OpenText™ Analytics Database supports the following hints:

General hints

Hint	Description
ALLNODES	Qualifies an EXPLAIN statement to request a query plan that assumes all nodes are active.
EARLY_MATERIALIZATION	Specifies early materialization of a table for the current query.
ENABLE_WITH_CLAUSE_MATERIALIZATION	Enables and disables WITH clause materialization for a specific query.
LABEL	Labels a query so you can identify it for profiling and debugging.
SKIP_STATISTICS	Directs the optimizer to produce a query plan that incorporates only minimal statistics.

Eon Mode hints

Hint	Description
DEPOT_FETCH	Specifies whether a query fetches data to the depot from communal storage when the depot lacks data for this query.
ECSMODE	Specifies the elastic crunch scaling (ECS) strategy for dividing shard data among its subscribers.

Join hints

Hint	Description
SYNTACTIC_JOIN	Enforces join order and enables other join hints.
DISTRIB	Sets the input operations for a distributed join to broadcast, resegment, local, or filter.
GBYTYPE	Specifies which algorithm—GROUPBY HASH or GROUPBY PIPELINED—the query optimizer should use to implement a GROUP BY clause.
JTYPE	Enforces the join type: merge or hash join.
UTYPE	Specifies how to combine UNION ALL input.

Projection hints

Hint	Description
PROJS	Specifies one or more projections to use for a queried table.
SKIP_PROJS	Specifies which projections to avoid using for a queried table.

Directed query hints

The following hints are only supported by directed queries:

Hint	Description
:c	Marks a query constant that must be included in an input query; otherwise, that input query is disqualified from using the directed query.
:v	Maps an input query constant to one or more annotated query constants.
VERBATIM	Enforces execution of an annotated query exactly as written.

Sql-Reference: Window clauses

Mon, 01 Jan 0001 00:00:00 +0000

When used with an analytic function, window clauses specify how to partition and sort function input, as well as how to frame input with respect to the current row. When used with a single-phase transform function, the PARTITION ROW and PARTITION LEFT JOIN window clauses support single-row partitions for single-phase transform functions, rather than analytic functions.

OpenText Analytics Database 26.2.x – Language elements

Sql-Reference: Keywords

Note

Reserved words and keywords

Note

Non-reserved keywords

Note

Viewing the list of reserved and non-reserved keywords

Sql-Reference: Identifiers

Unquoted identifiers

Caution

Quoted identifiers

Note

Case sensitivity

Non-ASCII characters

Identifiers are stored as created

Sql-Reference: Literals

Sql-Reference: Operators

Sql-Reference: Expressions

Operator precedence

Expression evaluation rules

Limits to SQL expressions

Sql-Reference: Lambda functions

Syntax

Arguments

Examples

Sql-Reference: Predicates

Sql-Reference: Hints

Restrictions

Supported hints

General hints

Eon Mode hints

Join hints

Projection hints

Directed query hints

Sql-Reference: Window clauses