From: Konstantin Osipov <kostja.osipov@gmail.com>
To: Nikita Pettik <korablev@tarantool.org>
Cc: tarantool-patches@freelists.org, tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [tarantool-patches] [PATCH v1 0/9] schema: rework _trigger space
Date: Wed, 16 Oct 2019 17:18:57 +0300 [thread overview]
Message-ID: <20191016141857.GA28254@atlas> (raw)
In-Reply-To: <20191016131315.GC12432@tarantool.org>
* Nikita Pettik <korablev@tarantool.org> [19/10/16 16:14]:
> > > > > Okay, let's enumerate all possible properties of _trigger space (I've taken
> > > > > version from the last RFC):
> > > > >
> > > > > - name (both have)
> > > >
> > > > If there will be persistent lua triggers, would it be possible to
> > > > drop them from SQL? With what construct? What will be their name
> > > > space (same name space as SQL triggers, or a distinct names space)?
> > > > Case sensitivity?
> > >
> > > IMHO there should be no opportunity to drop Lua NoSQL triggers from SQL;
> > > they should share different namespaces (as it happens now). The reason
> > > is that SQL triggers will be implemented as NoSQL on_replace triggers
> > > under the hood.
> >
> > This is true for non-persistent triggers. What if we ever decide
> > to persist Lua triggers?
>
> Why there should be any difference between them? Persisted Lua triggers
> have nothing in common with SQL triggers. They are just parsed and re-created
> after restart. Then they behave as normal (in-memory) NoSQL triggers.
Should they be "visible" to SQL? They certainly have effect on SQL
tables. If they are visible, should it be possible to enable,
disable, drop or modify them? If yes, what SQL syntax do you
suggest? If you suggest to use the same syntax as for SQL
triggers, the issue of trigger namespace arises.
--
Konstantin Osipov, Moscow, Russia
next prev parent reply other threads:[~2019-10-16 14:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-14 16:03 [Tarantool-patches] " Kirill Shcherbatov
2019-10-14 16:03 ` [Tarantool-patches] [PATCH v1 1/9] sql: remove redundant pointer in TriggerStep Kirill Shcherbatov
2019-10-15 15:35 ` [Tarantool-patches] [tarantool-patches] " Nikita Pettik
2019-10-14 16:03 ` [Tarantool-patches] [PATCH v1 2/9] box: rename struct trigger to lua_trigger Kirill Shcherbatov
2019-10-17 7:33 ` Konstantin Osipov
2019-10-14 16:03 ` [Tarantool-patches] [PATCH v1 3/9] box: introduce trigger_event_manipulation enum Kirill Shcherbatov
2019-10-17 7:35 ` Konstantin Osipov
2019-10-14 16:03 ` [Tarantool-patches] [PATCH v1 4/9] box: introduce trigger_action_timing enum Kirill Shcherbatov
2019-10-14 16:03 ` [Tarantool-patches] [PATCH v1 5/9] sql: use rlist to organize triggers in a list Kirill Shcherbatov
2019-10-17 7:36 ` Konstantin Osipov
2019-10-14 16:03 ` [Tarantool-patches] [PATCH v1 6/9] sql: rework CREATE TABLE rule in parser Kirill Shcherbatov
2019-10-14 16:03 ` [Tarantool-patches] [PATCH v1 7/9] sql: wrap all ASTs in sql_trigger_expr structure Kirill Shcherbatov
2019-10-14 16:03 ` [Tarantool-patches] [PATCH v1 8/9] sql: inherit sql_trigger from a new trigger class Kirill Shcherbatov
2019-10-17 7:38 ` Konstantin Osipov
2019-10-14 16:03 ` [Tarantool-patches] [PATCH v1 9/9] schema: rework _trigger system space Kirill Shcherbatov
2019-10-17 7:44 ` Konstantin Osipov
2019-10-15 21:34 ` [Tarantool-patches] [tarantool-patches] [PATCH v1 0/9] schema: rework _trigger space Nikita Pettik
2019-10-16 5:57 ` Konstantin Osipov
2019-10-16 5:58 ` Konstantin Osipov
2019-10-16 11:07 ` Nikita Pettik
2019-10-16 11:11 ` Konstantin Osipov
2019-10-16 12:18 ` Nikita Pettik
2019-10-16 12:32 ` Konstantin Osipov
2019-10-16 12:47 ` Nikita Pettik
2019-10-16 12:53 ` Konstantin Osipov
2019-10-16 13:13 ` Nikita Pettik
2019-10-16 14:18 ` Konstantin Osipov [this message]
2019-10-16 12:53 ` [Tarantool-patches] [tarantool-patches] " Kirill Shcherbatov
2019-10-16 13:31 ` Nikita Pettik
2019-10-16 13:47 ` Kirill Shcherbatov
2019-10-16 20:27 ` Vladislav Shpilevoy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191016141857.GA28254@atlas \
--to=kostja.osipov@gmail.com \
--cc=korablev@tarantool.org \
--cc=tarantool-patches@dev.tarantool.org \
--cc=tarantool-patches@freelists.org \
--subject='Re: [Tarantool-patches] [tarantool-patches] [PATCH v1 0/9] schema: rework _trigger space' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox