[
https://issues.apache.org/jira/browse/IGNITE-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-19759:
---------------------------------------
Description:
For the calcite engine we have too strict list of reserved keywords. For
example, lexems such as "TYPE" and "OPTIONS" are reserved keywords and can't be
used as columns or table names. But "TYPE" is frequently used by users as
column name and we should exclude it from the list of reserved keywords (add it
to non-reserved keywords, see {{config.fmpp}} file {{nonReservedKeywords}}
section). Other vendors allow to use "TYPE" as column name.
On the other hand Calcite-based SQL engine in Ignite now allows to use some
keywords which should not be allowed as table or column names, for example,
such query executes without any problem:
{noformat}
sql("create table true (like varchar, and int, as int)");
sql("insert into true values ('1', 1, 1)");
sql("select as as as from true where like like '%' and and between and
and and");
{noformat}
Current list of reserved keywords copied from "Babel" dialect of Calcite.
Calcite has "default" dialect with default list of reserved keywords (see [1]),
this list is close to SQL stantard, but looks quite strict too.
Other vendors lists are less restrictive. For example, in SQL standard build-in
functions and all built-in types are reserved keywords, in MySQL built-in
functions are not reserved, but build-in types are reserved, in PostgreeSQL
only minimal amount of keywords required for correct parsing are reserved
(built-in functions are not reserved, built-in types are not reserved). See
comparison table [2]. Our old SQL engine based on H2 database and H2 reserved
keywords (see [3]). H2 approach is close to PostgreeSQL approach (minimal
amount of keywords are reserved). I propose to use such an approach for Ignite
too, to maximaze compatibility between our SQL engines.
[1] https://calcite.apache.org/docs/reference.html#keywords
[2] https://en.wikipedia.org/wiki/List_of_SQL_reserved_words
[3] https://www.h2database.com/html/advanced.html#keywords
was:
For the calcite engine we have too strict list of reserved keywords. For
example, lexems such as "TYPE" and "OPTIONS" are reserved keywords and can't be
used as columns or table names. But "TYPE" is frequently used by users as
column name and we should exclude it from the list of reserved keywords (add it
to non-reserved keywords, see {{config.fmpp}} file \{{nonReservedKeywords}}
section). Other vendors allow to use "TYPE" as column name.
We should also review the whole list of reserved keywords (see generated
{{{}Parser.jj{}}}), perhaps some other keywords should be excluded from
reserved list too.
> Calcite engine. Review list of reserved keywords
> ------------------------------------------------
>
> Key: IGNITE-19759
> URL: https://issues.apache.org/jira/browse/IGNITE-19759
> Project: Ignite
> Issue Type: Improvement
> Reporter: Aleksey Plekhanov
> Assignee: Aleksey Plekhanov
> Priority: Major
> Labels: ise
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For the calcite engine we have too strict list of reserved keywords. For
> example, lexems such as "TYPE" and "OPTIONS" are reserved keywords and can't
> be used as columns or table names. But "TYPE" is frequently used by users as
> column name and we should exclude it from the list of reserved keywords (add
> it to non-reserved keywords, see {{config.fmpp}} file {{nonReservedKeywords}}
> section). Other vendors allow to use "TYPE" as column name.
> On the other hand Calcite-based SQL engine in Ignite now allows to use some
> keywords which should not be allowed as table or column names, for example,
> such query executes without any problem:
> {noformat}
> sql("create table true (like varchar, and int, as int)");
> sql("insert into true values ('1', 1, 1)");
> sql("select as as as from true where like like '%' and and between
> and and and");
> {noformat}
> Current list of reserved keywords copied from "Babel" dialect of Calcite.
> Calcite has "default" dialect with default list of reserved keywords (see
> [1]), this list is close to SQL stantard, but looks quite strict too.
> Other vendors lists are less restrictive. For example, in SQL standard
> build-in functions and all built-in types are reserved keywords, in MySQL
> built-in functions are not reserved, but build-in types are reserved, in
> PostgreeSQL only minimal amount of keywords required for correct parsing are
> reserved (built-in functions are not reserved, built-in types are not
> reserved). See comparison table [2]. Our old SQL engine based on H2 database
> and H2 reserved keywords (see [3]). H2 approach is close to PostgreeSQL
> approach (minimal amount of keywords are reserved). I propose to use such an
> approach for Ignite too, to maximaze compatibility between our SQL engines.
> [1] https://calcite.apache.org/docs/reference.html#keywords
> [2] https://en.wikipedia.org/wiki/List_of_SQL_reserved_words
> [3] https://www.h2database.com/html/advanced.html#keywords
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
