[tarantool-patches] Re: [PATCH] sql: add check for <WITH> absence in <CREATE VIEW>

[n.pettik]

> On 2 Aug 2019, at 15:52, Roman Khabibov <roman.habibov at tarantool.org> wrote:
> 
> Check that <CREATE VIEW> hasn't <WITH> after <AS>: "CREATE VIEW v
> AS WITH ... SELECT ...". Throw error, if it has.

What is the reason for that? I run example from ticket:

tarantool> \set language sql
tarantool> \set delimiter ;

tarantool> CREATE TABLE ts (s1 INT PRIMARY KEY);
tarantool> INSERT INTO ts VALUES (1);
tarantool> WITH RECURSIVE w AS (
         >             SELECT s1 FROM ts
         >             UNION ALL
         >             SELECT s1+1 FROM w WHERE s1 < 4)
         >           SELECT * FROM w;
tarantool> CREATE VIEW v AS WITH RECURSIVE w AS (
         >             SELECT s1 FROM ts
         >             UNION ALL
         >             SELECT s1+1 FROM w WHERE s1 < 4)
         >           SELECT * FROM w;
- null
- Space 'W' does not exist
...

So, it fails at the stage of view creation. Please, ask Peter
to provide valid example. Otherwise there’s no problem and
issue can be closed.

> 
> Closes #4149
> ---
> Branch: https://github.com/tarantool/tarantool/tree/romanhabibov/gh-4149-view
> Issue: https://github.com/tarantool/tarantool/issues/4149
> 
> src/box/sql/build.c        |  7 +++++++
> test/sql-tap/view.test.lua | 37 ++++++++++++++++++++++++++++++++++++-
> 2 files changed, 43 insertions(+), 1 deletion(-)
> 
> diff --git a/src/box/sql/build.c b/src/box/sql/build.c
> index ccec10543..e34202c9a 100644
> --- a/src/box/sql/build.c
> +++ b/src/box/sql/build.c
> @@ -1320,6 +1320,13 @@ sql_create_view(struct Parse *parse_context)
> 					    &create_entity_def->name);
> 	if (space == NULL || parse_context->is_aborted)
> 		goto create_view_fail;
> +	assert(view_def->select != NULL);
> +	if (view_def->select->pWith != NULL) {
> +		diag_set(ClientError, ER_CREATE_SPACE, space->def->name,
> +			 "can't create view as <WITH>");
> +			parse_context->is_aborted = true;
> +		goto create_view_fail;
> +	}

This looks like a crutch. Please, either find out if it is
possible to fix this at parser level (changing grammar),
or simply close issue.