The FROM clause specifies the target table(s) for SELECT, UPDATE, and DELETE statements.

Example Syntax:

• FROM table [[AS] alias]

• FROM table1 [INNER|LEFT OUTER|RIGHT OUTER|FULL OUTER] JOIN table2 ON join-criteria

• FROM table1 CROSS JOIN table2

• FROM (subquery) [AS] alias

• FROM TABLE(subquery) [AS] alias

• FROM table1 JOIN /*+ MAKEDEP */ table2 ON join-criteria

• FROM table1 JOIN /*+ MAKENOTDEP */ table2 ON join-criteria

• FROM /*+ MAKEIND */ table1 JOIN table2 ON join-criteria

• FROM /*+ NO_UNNEST */ vw1 JOIN table2 ON join-criteria

• FROM table1 left outer join /*+ optional */ table2 ON join-criteria

• FROM TEXTTABLE...

• FROM XMLTABLE...

• FROM ARRAYTABLE...

• FROM OBJECTTABLE...

• FROM (SELECT ...

From Clause Hints

From clause hints are typically specified in a comment block preceding the affected clause. If multiple hints apply to that clause, the hints should be placed in the same comment block.

FROM /*+ MAKEDEP PRESERVE */ (tbl1 inner join tbl2 inner join tbl3 on tbl2.col1 = tbl3.col1 on tbl1.col1 = tbl2.col1), tbl3 WHERE tbl1.col1 = tbl2.col1

Dependent Joins

MAKEIND, MAKEDEP, and MAKENOTDEP are hints used to control dependent join behavior. They should only be used in situations where the optimizer does not choose the most optimal plan based upon query structure, metadata, and costing information. The hints may appear in a comment that proceeds the from clause. The hints can be specified against any from clause, not just a named table.

• MAKEIND - treat this clause as the independent (feeder) side of a dependent join if possible.
• MAKEDEP - treat this clause as the dependent (filtered) side of a dependent join if possible.
• MAKENOTDEP - do not treat this clause as the dependent (filtered) side of a join.

Other Hints

NO_UNNEST can be specified against a subquery from clause or view to instruct the planner to not merge the nested SQL in the surrounding query - also known as view flattening. This hint only applies to Teiid planning and is not passed to source queries. NO_UNNEST may appear in a comment that proceeds the from clause.

The PRESERVE hint can be used against an ANSI join tree to preserve the structure of the join rather than allowing the Teiid optimizer to reorder the join. This is similar in function to the Oracle ORDERED or MySQL STRAIGHT_JOIN hints.

FROM /*+ PRESERVE */ (tbl1 inner join tbl2 inner join tbl3 on tbl2.col1 = tbl3.col1 on tbl1.col1 = tbl2.col1)

Nested Table Reference

Nested tables may appear in the FROM clause with the TABLE keyword. They are an alternative to using a view with normal join semantics. The columns projected from the command contained in the nested table may be used just as any of the other FROM clause projected columns in join criteria, the where clause, etc.

A nested table may have correlated references to preceding FROM clause column references as long as INNER and LEFT OUTER joins are used. This is especially useful in cases where then nested expression is a procedure or function call.

Valid example:

select * from t1, TABLE(call proc(t1.x)) t2

Invalid example, since t1 appears after the nested table in the from clause:

select * from TABLE(call proc(t1.x)) t2, t1

Multiple Execution The usage of a correlated nested table may result in multiple executions of the table expression - once for each correlated row.

TEXTTABLE

The TEXTTABLE function processes character input to produce tabular ouptut. It supports both fixed and delimited file format parsing. The function itself defines what columns it projects. The TEXTTABLE function is implicitly a nested table and may be correlated to preceding FROM clause entries.

Usage:

TEXTTABLE(expression [SELECTOR string] COLUMNS <COLUMN>, ... [NO ROW DELIMITER] [DELIMITER char] [(QUOTE|ESCAPE) char] [HEADER [integer]] [SKIP integer]) AS name

Where <COLUMN>

COLUMN := name (FOR ORDINALITY | datatype [WIDTH integer [NO TRIM]] [SELECTOR string integer])

Parameters

• expression - the text content to process, which should be convertible to CLOB.

• SELECTOR specifies that delimited lines should only match if the line begins with the selector string followed by a delimiter. The selector value is a valid column value. If a TEXTTABLE SELECTOR is specified, a SELECTOR may also be specified for column values. A column SELECTOR argument will select the nearest preceding text line with the given SELECTOR prefix and select the value at the given 1-based integer position (which includes the selector itself). If no such text line or position with a given line exists, a null value will be produced.

• NO ROW DELIMITER indicates that fixed parsing should not assume the presence of newline row delimiters.

• DELIMITER sets the field delimiter character to use. Defaults to ','.

• QUOTE sets the quote, or qualifier, character used to wrap field values. Defaults to '"'.

• ESCAPE sets the escape character to use if no quoting character is in use. This is used in situations where the delimiter or new line characters are escaped with a preceding character, e.g. \,

• HEADER specifies the text line number (counting every new line) on which the column names occur. All lines prior to the header will be skipped. If HEADER is specified, then the header line will be used to determine the TEXTTABLE column position by case-insensitive name matching. This is especially useful in situations where only a subset of the columns are needed. If the HEADER value is not specified, it defaults to 1. If HEADER is not specified, then columns are expected to match positionally with the text contents.

• SKIP specifies the number of text lines (counting every new line) to skip before parsing the contents. HEADER may still be specified with SKIP.

• A FOR ORDINALITY column is typed as integer and will return the 1-based item number as its value.

• WIDTH indicates the fixed-width length of a column in characters - not bytes. The CR NL newline value counts as a single character.

• NO TRIM specifies that the text value should not be trimmed of all leading and trailing white space.
  Syntax Rules:

• If width is specified for one column it must be specified for all columns and be a non-negative integer.

• If width is specified, then fixed width parsing is used and ESCAPE, QUOTE, SELECTOR, and HEADER should not be specified.

• If width is not specified, then NO ROW DELIMITER cannot be used.

• The columns names must be not contain duplicates.

Examples

• Use of the HEADER parameter, returns 1 row ['b']:

  SELECT * FROM TEXTTABLE(UNESCAPE('col1,col2,col3\na,b,c') COLUMNS col2 string HEADER) x

• Use of fixed width, returns 2 rows ['a', 'b', 'c'], ['d', 'e', 'f']:

  SELECT * FROM TEXTTABLE(UNESCAPE('abc\ndef') COLUMNS col1 string width 1, col2 string width 1, col3 string width 1) x

• Use of fixed width without a row delimiter, returns 3 rows ['a'], ['b'], ['c']:

  SELECT * FROM TEXTTABLE('abc' COLUMNS col1 string width 1 NO ROW DELIMITER) x

• Use of ESCAPE parameter, returns 1 row ['a,', 'b']:

  SELECT * FROM TEXTTABLE('a:,,b' COLUMNS col1 string, col2 string ESCAPE ':') x

• As a nested table:

  SELECT x.* FROM t, TEXTTABLE(t.clobcolumn COLUMNS first string, second date SKIP 1) x

• Use of SELECTORs, returns 2 rows ['c', 'd', 'b'], ['c', 'f', 'b']:

  SELECT * FROM TEXTTABLE('a,b\nc,d\nc,f' SELECTOR 'c' COLUMNS col1 string, col2 string col3 string SELECTOR 'a' 2) x

XMLTABLE

The XMLTABLE function uses XQuery to produce tabular ouput. The XMLTABLE function is implicitly a nested table and may be correlated to preceding FROM clause entries. XMLTABLE is part of the SQL/XML 2006 specification.

Usage:

XMLTABLE([<NSP>,] xquery-expression [<PASSING>] [COLUMNS <COLUMN>, ... )] AS name

COLUMN := name (FOR ORDINALITY | (datatype [DEFAULT expression] [PATH string]))

See XMLELEMENT for the definition of NSP - XMLNAMESPACES.

See XMLQUERY for the definition of PASSING.

See also XMLQUERY

See also XQuery Optimization

Parameters

• The optional XMLNAMESPACES clause specifies the namepaces for use in the XQuery and COLUMN path expressions.

• The xquery-expression should be a valid XQuery. Each sequence item returned by the xquery will be used to create a row of values as defined by the COLUMNS clause.

• If COLUMNS is not specified, then that is the same as having the COLUMNS clause: "COLUMNS OBJECT_VALUE XML PATH '.'", which returns the entire item as an XML value.

• A FOR ORDINALITY column is typed as integer and will return the 1-based item number as its value.

• Each non-ordinality column specifies a type and optionally a PATH and a DEFAULT expression.

• If PATH is not specified, then the path will be the same as the column name.
  Syntax Rules:

• Only 1 FOR ORDINALITY column may be specified.

• The columns names must be not contain duplicates.

• The blob datatype is supported, but there is only built-in support for xs:hexBinary values.  For xs:base64Binary, use a workaround of a PATH that uses the explicit value constructor "xs:base64Binary(<path>)".

Examples

Use of passing, returns 1 row [1]:

select * from xmltable('/a' PASSING xmlparse(document '<a id="1"/>') COLUMNS id integer PATH '@id') x

As a nested table:

select x.* from t, xmltable('/x/y' PASSING t.doc COLUMNS first string, second FOR ORDINALITY) x