gustavodemorais commented on code in PR #28737:
URL: https://github.com/apache/flink/pull/28737#discussion_r3613368602
##########
docs/content.zh/docs/sql/functions/built-in-functions.md:
##########
@@ -132,6 +132,24 @@ JSON 函数使用符合 ISO/IEC TR 19075-6 SQL标准的 JSON 路径表达式。
{{< sql_functions_zh "bitmapagg" >}}
+Table Functions
+---------------
+
+Table functions take zero, one, or more values as input and return multiple
rows (a table) as the result. Most built-in table functions take a table as an
input argument.
+Table functions can be used in two ways: as stand-alone inputs, where they are
invoked just once, or in a `LATERAL` context, where they are invoked for each
row of an outer table.
+
+| Function | Description
|
+|--------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `TUMBLE(data => TABLE t, ...)` | Assigns each row of the `data`
table to a tumbling window specified by additional window columns
(`window_start`, `window_end`, `window_time`). See [Window TVF]({{< ref
"docs/sql/reference/queries/window-tvf" >}}#tumble) for the full list of
arguments, semantics, and usage. |
+| `HOP(data => TABLE t, ...)` | Assigns each row of the `data`
table to a hopping window specified by additional window columns
(`window_start`, `window_end`, `window_time`). See [Window TVF]({{< ref
"docs/sql/reference/queries/window-tvf" >}}#hop) for the full list of
arguments, semantics, and usage. |
+| `CUMULATE(data => TABLE t, ...)` | Assigns each row of the `data`
table to a cumulating window specified by additional window columns
(`window_start`, `window_end`, `window_time`). See [Window TVF]({{< ref
"docs/sql/reference/queries/window-tvf" >}}#cumulate) for the full list of
arguments, semantics, and usage. |
+| `SESSION(data => TABLE t, ...)` | Assigns each row of the `data`
table to a session window specified by additional window columns
(`window_start`, `window_end`, `window_time`). See [Window TVF]({{< ref
"docs/sql/reference/queries/window-tvf" >}}#session) for the full list of
arguments, semantics, and usage. |
+| `FROM_CHANGELOG(input => TABLE t [, ...])` | Converts an append-only table
with an explicit operation column into a dynamic table. See Changelog
Conversion for the full list of arguments, semantics, and usage.
|
Review Comment:
ZH dropped {{< ref >}} changelog links; EN keeps them. Can we add them here?
##########
docs/content/docs/sql/reference/queries/joins.md:
##########
@@ -300,6 +300,101 @@ The main difference between above Temporal Table DDL and
Temporal Table Function
- The temporal table DDL can be defined in SQL but temporal table function can
not;
- Both temporal table DDL and temporal table function support temporal join
versioned table, but only temporal table function can temporal join the latest
version of any table/view.
+LATERAL SNAPSHOT Join
+--------------
+
+{{< label Streaming >}} {{< label Batch >}}
+
+A `LATERAL SNAPSHOT` join is a *stream enrichment* join that augments an
append-only table with the current state of an updating table.
+As in the [temporal joins](#temporal-joins), the enriched (left) input is
called the *probe side* and the enriching (right) input is called the *build
side*.
+Every probe-side row is joined with the build-side state that is current at
the time the row is processed.
+
+This is the same mode of operation as the [processing-time temporal
join](#processing-time-temporal-join), which also joins each probe-side row
against the latest build-side state.
+However, the processing-time temporal join has been disabled for Flink SQL due
to a fundamental limitation.
+The processing-time temporal join starts joining immediately when the query is
started: early probe-side rows are joined against whatever build-side rows
happen to have been loaded so far.
+Right after query start-up, the build side is typically still incomplete, so
early probe-side rows may be enriched with missing or stale data, and the
result depends on the order in which the two inputs are read.
+A `LATERAL SNAPSHOT` join addresses this problem by first loading the build
side up to a well-defined point in time (the *load phase*) before it starts
joining (the *join phase*).
Review Comment:
I think this is useful historical information but not the first thing a user
has to know when trying to find out about this feature by itself or just asking
himself what this feature is. I'd move it a bit down. Maybe under "How the join
works"?
##########
docs/content/docs/sql/reference/queries/joins.md:
##########
@@ -300,6 +300,101 @@ The main difference between above Temporal Table DDL and
Temporal Table Function
- The temporal table DDL can be defined in SQL but temporal table function can
not;
- Both temporal table DDL and temporal table function support temporal join
versioned table, but only temporal table function can temporal join the latest
version of any table/view.
+LATERAL SNAPSHOT Join
+--------------
+
+{{< label Streaming >}} {{< label Batch >}}
+
+A `LATERAL SNAPSHOT` join is a *stream enrichment* join that augments an
append-only table with the current state of an updating table.
+As in the [temporal joins](#temporal-joins), the enriched (left) input is
called the *probe side* and the enriching (right) input is called the *build
side*.
+Every probe-side row is joined with the build-side state that is current at
the time the row is processed.
+
Review Comment:
I'd probably suggest adding a very short sql example so users can
immediately picture what we're talking about
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
