[
https://issues.apache.org/jira/browse/CALCITE-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757003#comment-16757003
]
Stamatis Zampetakis commented on CALCITE-2812:
----------------------------------------------
Instead of "delta" I think it would be more appropriate to use the term
"transient" or "temporary" for such kind of tables. Both terms appear in the
SQL standard.
{quote}A transient table is a named table that may come into existence
implicitly during the evaluation of a <query
expression> or the execution of a trigger. A transient table is identified by a
<query name> if it arises during
the evaluation of a <query expression>, or by a <transition table name> if it
arises during the execution of a
trigger. Such tables exist only for the duration of the executing SQL-statement
containing the <query expression>
or for the duration of the executing trigger.
{quote}
{quote}A temporary base table is either a global temporary table, a created
local temporary table, or a declared local
temporary table
A global temporary table is a named table defined by a <table definition> that
specifies GLOBAL TEMPORARY.
Global temporary tables are effectively materialized only when referenced in an
SQL-session. Every SQL-
session that references a global temporary table causes a distinct instance of
that global temporary table (i.e.,
a multiset of rows that is visible only to that SQL-session) to be
materialized. That is, the multiset of rows that
is reference by the <table name> of a global temporary table cannot be shared
between SQL-sessions.
{quote}
Since the delta table comes into existence only for the execution of the query,
maybe the "transient" term is more appropriate.
> Add algebraic operators to allow expressing recursive queries
> -------------------------------------------------------------
>
> Key: CALCITE-2812
> URL: https://issues.apache.org/jira/browse/CALCITE-2812
> Project: Calcite
> Issue Type: New Feature
> Components: core
> Affects Versions: 1.18.0
> Reporter: Stamatis Zampetakis
> Assignee: Julian Hyde
> Priority: Major
> Fix For: next
>
>
> In order to parse, optimize, and execute, recursive queries, expressed in
> SQL, datalog, SPARQL, or other high level language we need first to be able
> to represent recursive queries in relational algebra.
> The subject has been previously discussed in the dev list (see thread with
> title [Recursive query, graph query,
> Datalog|http://mail-archives.apache.org/mod_mbox/calcite-dev/201712.mbox/%3CCAPSgeESFyih9_hf9=uMWFN00BCR7sjf0T+FRY2=ary3ygm1...@mail.gmail.com%3E])
> where various ideas and optimizations were proposed.
> In this issue, we attempt to address only the algebraic part providing the
> following:
> # logical operator(s) for expressing recursion;
> # naive physical operator(s) for the Enumerable convention;
> # ability to create a recusive plan using the RelBuilder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
