Hi，stefan and Dave,
I do not intend to implement the BNF of COPY TABLE based on the BNF of
CREATE TABLE. All table options are indeed copied by default. Therefore,
the following syntax is not supported:
CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name WITH TRIGGERS
> AND VIEWS AND compaction = { 'class' : 'LeveledCompactionStrategy' } AND
> default_time_to_live = 86400;
We can see that the above statement itself is very complicated because it
provides too many choices.
If we support individual settings of table options
(compaction/compression), what about other TRIGGER/INDEXS ? I tend to treat
the table, TRIGGER, INDEX, etc. as a whole and copy them uniformly. As for
their own attributes, such as table options, INDEX attributes, etc., they
can be copied and then set manually.
So we only going to support :
> 1.CREATE TABLE newks.newtable LIKE oldks.oldtable
> 2.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH ALL // this means
> copy indexes and triggers
> 3.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH INDEXES
> 4.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH TRIGGERS
> 5.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH TRIGGERS AND
> INDEXES // equal to option 2.
Štefan Miklošovič <smikloso...@apache.org> 于2024年11月4日周一 23:31写道：
> 1) Just mention that it will not be part of phase 1, I am OK if it will be
> delivered later.
>
> 2) If we had "ALL" introduced, then we would have something like this:
>
> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name
> WITH
> ALL
> AND compaction = { 'class' : 'LeveledCompactionStrategy' }
> AND default_time_to_live = 86400;
>
> I think this is a little bit "strange". It would make sense to add ALL if
> we have not had any "AND"s but mixing ALL and then adding AND with options
> is a little bit confusing.
>
> 3)
>
> Do I understand correctly that your CEP will make this possible? I do not
> want to go into the implementation details for now.
>
> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name
> WITH TRIGGERS
> AND VIEWS
> AND compaction = { 'class' : 'LeveledCompactionStrategy' }
> AND default_time_to_live = 86400;
>
> In other words, it will copy all options from "cycling.cyclist_name" while
> it will be possible to override the options with whatever I want? Basically
> what Dave suggested.
>
>
> On Mon, Nov 4, 2024 at 4:21 PM guo Maxwell <cclive1...@gmail.com> wrote:
>
>> Hi stefan
>> 1、yes, cross-keyspace copying will be much complicated than copying under
>> same keyspace , but I think we can support it in the future , and I think
>> it is under the scope of this CEP , so I add it .Or is it that the work
>> planned for the next step should not be listed here for the time being?
>> I don't know the rules very well here, and I hope if you can help point
>> out the unreasonable points 😀 , because I do plan to complete this
>> task, although I have only implemented the same keyspace now.
>> 2、yes, you are right, I gave up ALL at the first time , But after I
>> replied to yifan’s email, I communicated with him privately through slack.
>> In the end, I was not strongly opposed to ALL (Sorry, we communicated in
>> Chinese, https://the-asf.slack.com/archives/D07SXB787HN/p1729136909357689),
>> In addition, I later saw that you were +0, so I added ALL back.
>> 3、the change to Parse.g will be like :
>>
>>> /**
>>> * CREATE TABLE [IF NOT EXISTS] <NEW_TABLE>
>>> * LIKE <OLD_TABLE>
>>> * [ WITH OPTIONS AND INDEXES AND TRIGGERS ]
>>> */
>>> copyTableStatement returns [CopyTableStatement.Raw stmt]
>>> @init { boolean ifNotExists = false; }
>>> : K_CREATE K_COLUMNFAMILY newCf=columnFamilyName LIKE
>>> oldCf=columnFamilyName
>>> { $stmt = new CopyTableStatement.Raw(newCf, oldCf); }
>>> tableLikeOptions[stmt]
>>> ;
>>>
>>> tableLikeOptions[CopyTableStatement.Raw stmt]
>>> : ( K_WITH tableLikeSingleOption[stmt] ( K_AND
>>> tableLikeSingleOption[stmt] )*)?
>>> ;
>>>
>>> tableLikeSingleOption[CopyTableStatement.Raw stmt]
>>> : option=STRING_LITERAL { $stmt.extendWithLikeOptions($option.text); }
>>> ;
>>>
>>> I don’t plan to reuse the Create table definition file, and there
>> doesn’t seem to be much need. And I have made a explanation in the cep
>> file
>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-43++Apache+Cassandra+CREATE+TABLE++LIKE>
>>
>> Thanks.
>>
>> Štefan Miklošovič <smikloso...@apache.org> 于2024年11月4日周一 17:00写道：
>>
>>> Hi Maxwell,
>>>
>>> 1) I noticed that there is table copying across keyspaces in your goal
>>> number 2) in the CEP. Is this correct? I was thinking that we are doing
>>> same-keyspace copying for now and it will be considered later, as you
>>> elaborate on that further down the document. Cross-keyspace copying would
>>> mean (among other things) that we would need to create UDTs in another
>>> keyspace as well which would complicate it etc ...
>>>
>>> 2) I also see this
>>>
>>> CREATE TABLE <NEW_TABLE> LIKE <OLD_TABLE> [ WITH ALL | [ INDEXES AND
>>> TRIGGERS]]
>>>
>>> Is this really correct? I think we agreed that ALL will not be
>>> supported. You gave up on ALL in this comment of yours (the first sentence)
>>> (1)
>>>
>>> 3) It would be great if you were more explicit about the proposed CQL
>>> changes in such a way that after the CEP is delivered, it would be possible
>>> to override the options on a new table. Basically what Dave summarized here
>>> (2) at the very bottom. All three examples should be mentioned in CEP for
>>> being explicit about our intentions.
>>>
>>> After this is all reflected, I will be glad to vote on this CEP in the
>>> other thread.
>>>
>>> (1) https://lists.apache.org/thread/d485w6lxvpoztmjnxj8msj0jjt3d5ltk
>>> (2) https://lists.apache.org/thread/odc1s1pt5m2tk76owxq61y55kytf13sf
>>>
>>> On Wed, Oct 30, 2024 at 4:28 AM guo Maxwell <cclive1...@gmail.com>
>>> wrote:
>>>
>>>> So we should be able to start voting on this now.
>>>>
>>>> guo Maxwell <cclive1...@gmail.com> 于2024年10月28日周一 17:20写道：
>>>>
>>>>> Here is the latest updated CEP-43
>>>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-43++Apache+Cassandra+CREATE+TABLE++LIKE>
>>>>>
>>>>>
>>>>> guo Maxwell <cclive1...@gmail.com> 于2024年10月24日周四 19:53写道：
>>>>>
>>>>>> yes，you are right. I will add this
>>>>>>
>>>>>> Štefan Miklošovič <smikloso...@apache.org>于2024年10月24日 周四下午4:42写道：
>>>>>>
>>>>>>> The CEP should also mention that copying system tables or virtual
>>>>>>> tables or materialized views and similar are not supported and an
>>>>>>> attempt
>>>>>>> of doing so will error out.
>>>>>>>
>>>>>>> On Thu, Oct 24, 2024 at 7:16 AM Dave Herrington <
>>>>>>> he...@rhinosource.com> wrote:
>>>>>>>
>>>>>>>> Strong +1 to copy all options by default. This is intuitive to me.
>>>>>>>> Then I would like to explicitly override any options of my choosing.
>>>>>>>>
>>>>>>>> -Dave
>>>>>>>>
>>>>>>>> On Wed, Oct 23, 2024 at 9:57 PM guo Maxwell <cclive1...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> OK，thank you for your suggestions ，I will revise the CEP and copy
>>>>>>>>> table OPTIONS by default.
>>>>>>>>>
>>>>>>>>> Jon Haddad <j...@rustyrazorblade.com>于2024年10月23日 周三下午9:18写道：
>>>>>>>>>
>>>>>>>>>> Also strongly +1 to copying all the options.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Oct 23, 2024 at 5:52 AM Josh McKenzie <
>>>>>>>>>> jmcken...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> I'm a very strong +1 to having the default functionality be to
>>>>>>>>>>> copy *ALL* options.
>>>>>>>>>>>
>>>>>>>>>>> Intuitively, as a user, if I tell a software system to make a
>>>>>>>>>>> clone of something I don't expect it to be shallow or a subset
>>>>>>>>>>> defined by
>>>>>>>>>>> some external developer somewhere. I expect it to be a clone.
>>>>>>>>>>>
>>>>>>>>>>> Adding in some kind of "lean" mode or "column only" is fine if
>>>>>>>>>>> someone can make a cogent argument around its inclusion. I don't
>>>>>>>>>>> personally
>>>>>>>>>>> see a use-case for it right now but definitely open to being
>>>>>>>>>>> educated.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 23, 2024, at 3:03 AM, Štefan Miklošovič wrote:
>>>>>>>>>>>
>>>>>>>>>>> options are inherently part of that table as well, same as
>>>>>>>>>>> schema. In fact, _schema_ includes all options. Not just columns
>>>>>>>>>>> and its
>>>>>>>>>>> names. If you change some option, you effectively have a different
>>>>>>>>>>> schema,
>>>>>>>>>>> schema version changes by changing an option. So if we do not copy
>>>>>>>>>>> options
>>>>>>>>>>> too, we are kind of faking it (when we do not specify WITH OPTIONS).
>>>>>>>>>>>
>>>>>>>>>>> Also, imagine a situation where Accord is merged to trunk. It
>>>>>>>>>>> introduces a new schema option called "transactional = full" which
>>>>>>>>>>> is not
>>>>>>>>>>> default. (I am sorry if I did the spelling wrong here). So, when
>>>>>>>>>>> you have a
>>>>>>>>>>> table with transactional support and you do "create table
>>>>>>>>>>> ks.tb_copy like
>>>>>>>>>>> ks.tb", when you _do not_ copy all options, this table will _not_
>>>>>>>>>>> become
>>>>>>>>>>> transactional.
>>>>>>>>>>>
>>>>>>>>>>> The next thing you go to do is to execute some transactions
>>>>>>>>>>> against this table but well ... you can not do that, because your
>>>>>>>>>>> table is
>>>>>>>>>>> not transactional, because you have forgotten to add "WITH
>>>>>>>>>>> OPTIONS". So you
>>>>>>>>>>> need to go back to that and do "ALTER ks.tb_copy WITH transactional
>>>>>>>>>>> = full"
>>>>>>>>>>> just to support that.
>>>>>>>>>>>
>>>>>>>>>>> I think that you see from this pattern that it is way better if
>>>>>>>>>>> we copy all options by default instead of consciously opt-in into
>>>>>>>>>>> them.
>>>>>>>>>>>
>>>>>>>>>>> also:
>>>>>>>>>>>
>>>>>>>>>>> "but I think there are also some users want to do basic column
>>>>>>>>>>> information copy"
>>>>>>>>>>>
>>>>>>>>>>> where is this coming from? Do you have this idea somehow
>>>>>>>>>>> empirically tested? I just do not see why somebody would want to
>>>>>>>>>>> have
>>>>>>>>>>> Cassandra's defaults instead of what a base table contains.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 23, 2024 at 8:28 AM guo Maxwell <
>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> The reason for using OPTION keyword is that I want to provide
>>>>>>>>>>> users with more choices .
>>>>>>>>>>> The default behavior for copying a table is to copy the basic
>>>>>>>>>>> item of table （column and their data type，mask，constraint），others
>>>>>>>>>>> thing
>>>>>>>>>>> belongs to the table like option，views，trigger
>>>>>>>>>>> are optional in my mind.
>>>>>>>>>>> You are absolutely right that users may want to copy all stuff
>>>>>>>>>>> but I think there are aslo some users want to do basic column
>>>>>>>>>>> information
>>>>>>>>>>> copy，So I just give them a choice。As we know that the number of
>>>>>>>>>>> table
>>>>>>>>>>> parameters is not
>>>>>>>>>>> small，compression，compaction，gc_seconds，bf_chance，speculative_retry
>>>>>>>>>>> and so
>>>>>>>>>>> on.
>>>>>>>>>>>
>>>>>>>>>>> Besides we can see that pg have also the keyword
>>>>>>>>>>> COMMENT，COMPRESSION which have the similar behavior as our OPTION
>>>>>>>>>>> keyword。
>>>>>>>>>>>
>>>>>>>>>>> So that is why I add this keyword OPTION.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Štefan Miklošovič <smikloso...@apache.org>于2024年10月22日
>>>>>>>>>>> 周二下午11:40写道：
>>>>>>>>>>>
>>>>>>>>>>> The problem is that when I do this minimal CQL which shows this
>>>>>>>>>>> feature:
>>>>>>>>>>>
>>>>>>>>>>> CREATE TABLE ks.tb_copy LIKE ks.tb;
>>>>>>>>>>>
>>>>>>>>>>> then you are saying that when I _do not_ specify WITH OPTIONS
>>>>>>>>>>> then I get Cassandra's defaults. Only after I specify WITH OPTIONS,
>>>>>>>>>>> it
>>>>>>>>>>> would truly be a copy.
>>>>>>>>>>>
>>>>>>>>>>> This is not a good design. Because to have an exact copy, I have
>>>>>>>>>>> to make a conscious effort to include OPTIONS as well. That should
>>>>>>>>>>> not be
>>>>>>>>>>> the case. I just want to have a copy, totally the same stuff, when
>>>>>>>>>>> I use
>>>>>>>>>>> the minimal version of that statement. It would be better to
>>>>>>>>>>> opt-out from
>>>>>>>>>>> options like
>>>>>>>>>>>
>>>>>>>>>>> CREATE TABLE ks.tb_copy LIKE ks.tb WITHOUT OPTIONS (you feel me)
>>>>>>>>>>> but we do not support this (yet).
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Oct 22, 2024 at 5:28 PM Štefan Miklošovič <
>>>>>>>>>>> smikloso...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I just don't see OPTIONS as important. When I want to copy a
>>>>>>>>>>> table, I am copying a table _with everything_. Options included, by
>>>>>>>>>>> default. Why would I want to have a copy of a table with options
>>>>>>>>>>> different
>>>>>>>>>>> from the base one?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Oct 21, 2024 at 3:55 PM Bernardo Botella <
>>>>>>>>>>> conta...@bernardobotella.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Guo,
>>>>>>>>>>>
>>>>>>>>>>> +1 for the CONSTRAINTS keyword to be added into the default
>>>>>>>>>>> behavior.
>>>>>>>>>>>
>>>>>>>>>>> Bernardo
>>>>>>>>>>>
>>>>>>>>>>> On Oct 21, 2024, at 12:01 AM, guo Maxwell <cclive1...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I think the CONSTRAINTS keyword keyword may be in the same
>>>>>>>>>>> situation as datamask.
>>>>>>>>>>> Maybe it is better to include constraints into the default
>>>>>>>>>>> behavior of table copy together with column name, column data type
>>>>>>>>>>> and data
>>>>>>>>>>> mask.
>>>>>>>>>>>
>>>>>>>>>>> guo Maxwell <cclive1...@gmail.com> 于2024年10月21日周一 14:56写道：
>>>>>>>>>>>
>>>>>>>>>>> To yifan :
>>>>>>>>>>> I don't mind adding the ALL keyword, and it has been updated
>>>>>>>>>>> into CEP.
>>>>>>>>>>>
>>>>>>>>>>> As all you can see, our original intention was that the grammar
>>>>>>>>>>> would not be too complicated, which is what I described in cep
>>>>>>>>>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-43++Apache+Cassandra+CREATE+TABLE++LIKE>
>>>>>>>>>>> .
>>>>>>>>>>> We gave up PG-related grammar, including INCLUDING/EXCLUDING and
>>>>>>>>>>> so on .
>>>>>>>>>>>
>>>>>>>>>>> guo Maxwell <cclive1...@gmail.com> 于2024年10月21日周一 14:52写道：
>>>>>>>>>>>
>>>>>>>>>>> Hi ,
>>>>>>>>>>> To sefan :
>>>>>>>>>>> I may want to explain that if there is no OPTION keyword in the
>>>>>>>>>>> CQL statement, then the newly created table will only have the
>>>>>>>>>>> original table's column name 、column type and data mask ,I think
>>>>>>>>>>> this is
>>>>>>>>>>> the most basic choice when copying tables to users.
>>>>>>>>>>> Then we do some addition, we can add original table's table
>>>>>>>>>>> options like compaction strategy/compress strategy、index and so on.
>>>>>>>>>>>
>>>>>>>>>>> Recently, I have also thought about the situation of CONSTRAINTS
>>>>>>>>>>> keyword. I think it is similar to data mask. Agree that it should be
>>>>>>>>>>> included in the basic options of table copy (column name, column
>>>>>>>>>>> data type
>>>>>>>>>>> , column data mask and constraints).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Dave Herrington <he...@rhinosource.com> 于2024年10月19日周六 01:15写道：
>>>>>>>>>>>
>>>>>>>>>>> It seems like a natural extension of the CREATE TABLE
>>>>>>>>>>> statement. Looking forward to using it in the future.
>>>>>>>>>>>
>>>>>>>>>>> -Dave
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 17, 2024 at 5:11 PM Štefan Miklošovič <
>>>>>>>>>>> smikloso...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Right?! Reads like English, the impact on the existing CQL is
>>>>>>>>>>> minimal. One LIKE which basically needs to be there and keywords of
>>>>>>>>>>> logical
>>>>>>>>>>> "components" which seamlessly integrate with WITH.
>>>>>>>>>>>
>>>>>>>>>>> I would _not_ use WITH CONSTRAINTS because constraints will be
>>>>>>>>>>> inherently part of a table schema. It is not an "option". We can not
>>>>>>>>>>> "opt-out" from them. Remember we are copying a table here so if a
>>>>>>>>>>> base one
>>>>>>>>>>> has constraints, its copy will have them too. A user can
>>>>>>>>>>> subsequently
>>>>>>>>>>> "ALTER" them.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 17, 2024 at 5:31 PM Dave Herrington <
>>>>>>>>>>> he...@rhinosource.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Basing it on CREATE TABLE, the BNF definition of the simple
>>>>>>>>>>> implementation would look something like this:
>>>>>>>>>>>
>>>>>>>>>>> create_table_statement::= CREATE TABLE [ IF NOT EXISTS ]
>>>>>>>>>>> table_name LIKE base_table_name
>>>>>>>>>>> [ WITH included_objects ] [ [ AND ] table_options ]
>>>>>>>>>>> table_options::= COMPACT STORAGE [ AND table_options ]
>>>>>>>>>>> | CLUSTERING ORDER BY '(' clustering_order ')'
>>>>>>>>>>> [ AND table_options ] | options
>>>>>>>>>>> clustering_order::= column_name (ASC | DESC) ( ',' column_name
>>>>>>>>>>> (ASC | DESC) )*
>>>>>>>>>>> included_objects::= dependent_objects [ AND dependent_objects ]
>>>>>>>>>>> dependent_objects:= INDEXES | TRIGGERS | CONSTRAINTS | VIEWS
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> CREATE TABLE [ IF NOT EXISTS ] [<keyspace_name>.]<table_name>
>>>>>>>>>>> LIKE [<keyspace_name>.]<base_table_name>
>>>>>>>>>>> [ WITH [ <included_objects > ]
>>>>>>>>>>> [ [ AND ] [ <table_options> ] ]
>>>>>>>>>>> [ [ AND ] CLUSTERING ORDER BY [ <clustering_column_name> (ASC
>>>>>>>>>>> | DESC) ] ]
>>>>>>>>>>> ;
>>>>>>>>>>>
>>>>>>>>>>> Examples:
>>>>>>>>>>>
>>>>>>>>>>> -- Create base table:
>>>>>>>>>>> CREATE TABLE cycling.cyclist_name (
>>>>>>>>>>> id UUID PRIMARY KEY,
>>>>>>>>>>> lastname text,
>>>>>>>>>>> firstname text
>>>>>>>>>>> );
>>>>>>>>>>>
>>>>>>>>>>> -- Create an exact copy of the base table, but do not create any
>>>>>>>>>>> dependent objects:
>>>>>>>>>>> CREATE TABLE cycling.cyclist_name2 LIKE cycling.cyclist_name;
>>>>>>>>>>>
>>>>>>>>>>> -- Create an exact copy with all dependent objects (constraints
>>>>>>>>>>> excluded for now):
>>>>>>>>>>> CREATE TABLE cycling.cyclist_name3 LIKE cycling.cyclist_name
>>>>>>>>>>> WITH INDEXES AND TRIGGERS AND VIEWS;
>>>>>>>>>>>
>>>>>>>>>>> -- Create a copy with LCS compaction, a default TTL and all
>>>>>>>>>>> dependent objects except indexes:
>>>>>>>>>>> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name
>>>>>>>>>>> WITH TRIGGERS AND VIEWS
>>>>>>>>>>> AND compaction = { 'class' : 'LeveledCompactionStrategy' }
>>>>>>>>>>> AND default_time_to_live = 86400;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This seems pretty clean & straightforward.
>>>>>>>>>>>
>>>>>>>>>>> -Dave
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 17, 2024 at 4:05 PM Dave Herrington <
>>>>>>>>>>> he...@rhinosource.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> This simple approach resonates with me. I think the Cassandra
>>>>>>>>>>> doc uses "INDEXES" as the plural for index, i.e.:
>>>>>>>>>>> https://cassandra.apache.org/doc/stable/cassandra/cql/indexes.html
>>>>>>>>>>>
>>>>>>>>>>> -Dave
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 17, 2024 at 2:39 PM Štefan Miklošovič <
>>>>>>>>>>> smikloso...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Well we could do something like:
>>>>>>>>>>>
>>>>>>>>>>> CREATE TABLE ks.tb_copy LIKE ks.tb WITH INDICES AND TRIGGERS AND
>>>>>>>>>>> compaction = {'class': '.... } AND ...
>>>>>>>>>>>
>>>>>>>>>>> but I can admit it might be seen as an overreach and I am not
>>>>>>>>>>> sure at all how it would look like in the implementation because we
>>>>>>>>>>> would
>>>>>>>>>>> need to distinguish WITH INDICES from table options.
>>>>>>>>>>>
>>>>>>>>>>> I would
>>>>>>>>>>>
>>>>>>>>>>> 1. +0 on ALL. - we don't need this. If we have just INDICES,
>>>>>>>>>>> TRIGGERS, VIEWS at this point, I don't think enumerating it all
>>>>>>>>>>> is too much
>>>>>>>>>>> to ask. This is just an implementation detail and if we find it
>>>>>>>>>>> necessary
>>>>>>>>>>> we can add it later. If you feel strongly about this then add
>>>>>>>>>>> that but it
>>>>>>>>>>> is not absolutely necessary.
>>>>>>>>>>> 2. omit OPTIONS - aren't all options copied by default? That
>>>>>>>>>>> is the goal of the CEP, no? We might just use normal CQL
>>>>>>>>>>> while overriding from the base table
>>>>>>>>>>> 3. mix keywords like TRIGGERS / INDICES / CONSTRAINTS into
>>>>>>>>>>> normal table creation statement
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 17, 2024 at 3:20 PM Yifan Cai <yc25c...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I would second Štefan's option for functionality simplicity. It
>>>>>>>>>>> seems to be unnecessary to have the keywords for both inclusion and
>>>>>>>>>>> exclusion in the CEP. If needed, the exclusion (WITHOUT) can be
>>>>>>>>>>> introduced
>>>>>>>>>>> later. It would still be backward compatible.
>>>>>>>>>>>
>>>>>>>>>>> Regarding "CREATE TABLE ks.tb_copy LIKE ks.tb WITH compaction =
>>>>>>>>>>> {'class': '.... } AND ... ", I think it only overrides the table
>>>>>>>>>>> options.
>>>>>>>>>>> The CEP suggests the coarse-grained keyword for each category like
>>>>>>>>>>> table
>>>>>>>>>>> options, indexes, etc. The functionality provided is not identical.
>>>>>>>>>>>
>>>>>>>>>>> I understand that the suggestions are to make operators' life
>>>>>>>>>>> easier by achieving table creation in a single statement. What is
>>>>>>>>>>> being
>>>>>>>>>>> proposed in the CEP seems to be at a good balance point. Operators
>>>>>>>>>>> can
>>>>>>>>>>> alter the table options if needed in the follow-up ALTER table
>>>>>>>>>>> statement.
>>>>>>>>>>>
>>>>>>>>>>> - Yifan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 17, 2024 at 1:41 PM Štefan Miklošovič <
>>>>>>>>>>> smikloso...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I think we are starting to complicate it. For me the most
>>>>>>>>>>> important question is who is actually this feature for? If people
>>>>>>>>>>> want to
>>>>>>>>>>> just prototype something fast or they just want to have "the same
>>>>>>>>>>> table
>>>>>>>>>>> just under a different name", I think that is going to be used in
>>>>>>>>>>> 99% of
>>>>>>>>>>> cases.
>>>>>>>>>>>
>>>>>>>>>>> My assumption of using WITH which I think I proposed first (4th
>>>>>>>>>>> post in this thread) was to just blindly copy the most important
>>>>>>>>>>> "parts"
>>>>>>>>>>> logically related to a table, be it indices, materialized views, or
>>>>>>>>>>> triggers and enable / disable them as we wish. If no "WITH" is
>>>>>>>>>>> used, then
>>>>>>>>>>> we just get a table with nothing else. "WITH" will opt-in into that.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Seeing us contemplating using "INCLUDING" and "EXCLUDING" on
>>>>>>>>>>> individual options makes me sad a little bit. I think we are
>>>>>>>>>>> over-engineering this. I just don't see a reasonable use-case where
>>>>>>>>>>> users
>>>>>>>>>>> would need to cherry-pick what they want and what not. Isn't that
>>>>>>>>>>> just too
>>>>>>>>>>> complicated? If a table being copied drifts away too much from the
>>>>>>>>>>> original
>>>>>>>>>>> one then users would be better off with creating a brand new table
>>>>>>>>>>> with CQL
>>>>>>>>>>> as they are used to, not dealing with "copying" at all. More we
>>>>>>>>>>> drift from
>>>>>>>>>>> what the original table was like, the less useful this feature is.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 16, 2024 at 10:03 PM Dave Herrington <
>>>>>>>>>>> he...@rhinosource.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Sorry that I overlooked the definition of the default in the
>>>>>>>>>>> CEP. I did look for it but I didn’t see it.
>>>>>>>>>>>
>>>>>>>>>>> I think the default behavior you explained makes perfect sense &
>>>>>>>>>>> what one would expect.
>>>>>>>>>>>
>>>>>>>>>>> I like the flexibility of INCLUDING and EXCLUDING that you are
>>>>>>>>>>> considering.
>>>>>>>>>>>
>>>>>>>>>>> Would it make sense to use WITH for table options, which would
>>>>>>>>>>> make it easy (and less confusing IMHO) to override the defaults
>>>>>>>>>>> from the
>>>>>>>>>>> source table, then use INCLUDING/EXCLUDING for all non-table
>>>>>>>>>>> options such
>>>>>>>>>>> as constraints and indices?
>>>>>>>>>>>
>>>>>>>>>>> It seems this would be easier to document as well, as it could
>>>>>>>>>>> just point to the CREATE TABLE doc for the options, rather than
>>>>>>>>>>> trying to
>>>>>>>>>>> explain a bunch of keywords that map to table options.
>>>>>>>>>>>
>>>>>>>>>>> -Dave
>>>>>>>>>>>
>>>>>>>>>>> David A. Herrington II
>>>>>>>>>>> President and Chief Engineer
>>>>>>>>>>> RhinoSource, Inc.
>>>>>>>>>>>
>>>>>>>>>>> *Data Lake Architecture, Cloud Computing and Advanced Analytics.*
>>>>>>>>>>>
>>>>>>>>>>> www.rhinosource.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 16, 2024 at 7:57 PM guo Maxwell <
>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> To yifan :
>>>>>>>>>>> At the beginning of the period, I also thought about adding the
>>>>>>>>>>> keyword ALL, refer to pg
>>>>>>>>>>> <https://www.postgresql.org/docs/current/sql-createtable.html> ,
>>>>>>>>>>> but I give up when writing cep as I find that there may be not so
>>>>>>>>>>> many
>>>>>>>>>>> properties (only three) to copy for C* and
>>>>>>>>>>> It is possible to decide what is needed and what is not in a
>>>>>>>>>>> very simple cql, as our ALL is only three properties here. I want
>>>>>>>>>>> to keep
>>>>>>>>>>> it as simple as possible (based on the advice given by Benjamin),
>>>>>>>>>>> So I
>>>>>>>>>>> grouped
>>>>>>>>>>> the properties of the table into one category and expressed it
>>>>>>>>>>> with OPTION keyword.
>>>>>>>>>>>
>>>>>>>>>>> But if we are going to split the first keyword OPTION to
>>>>>>>>>>> COMPRESSION 、COMPACTION、COMMENT and so on. I am +1 on adding ALL
>>>>>>>>>>> back as
>>>>>>>>>>> the properties are so many and it is simple to use ALL instead of
>>>>>>>>>>> list all properties. Besides I may change my keyword WITH to
>>>>>>>>>>> INCLUDING and adding another keyword EXCLUDING to flexibly copy
>>>>>>>>>>> table
>>>>>>>>>>> properties through simple sql statements, like using 1 not 2
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 1. CREATE TABLE newTb like oldTb INCLUDING ALL EXCLUDING
>>>>>>>>>>> INDEXES AND COMMENTS.
>>>>>>>>>>> 2. CREATE TABLE newTb like oldTb INCLUDING COMPRESSION
>>>>>>>>>>> CONSTRAINTS GENERATED IDENTITY STATISTICS STORAGE
>>>>>>>>>>>
>>>>>>>>>>> Conclusion: If there may be more keywords to consider in the
>>>>>>>>>>> future, such as more than 4 , I am +1 on adding ALL back .
>>>>>>>>>>>
>>>>>>>>>>> To Dave :
>>>>>>>>>>> Default behavior is only copy column name, data type ,data
>>>>>>>>>>> mask , you can see more detail from CEP-43
>>>>>>>>>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-43++Apache+Cassandra+CREATE+TABLE++LIKE>
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Patrick McFadin <pmcfa...@gmail.com> 于2024年10月17日周四 06:43写道：
>>>>>>>>>>>
>>>>>>>>>>> +1 That makes much more sense in my experience.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 16, 2024 at 12:12 PM Dave Herrington <
>>>>>>>>>>> he...@rhinosource.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I'm coming at this with both a deep ANSI SQL background as well
>>>>>>>>>>> as CQL background.
>>>>>>>>>>>
>>>>>>>>>>> Defining the default behavior is the starting point. What gets
>>>>>>>>>>> copied if we do "CREATE TABLE new_table LIKE original_table;"
>>>>>>>>>>> without a
>>>>>>>>>>> WITH clause?
>>>>>>>>>>>
>>>>>>>>>>> Then, you build on that with the specific WITH options. WITH
>>>>>>>>>>> ALL catches everything.
>>>>>>>>>>>
>>>>>>>>>>> -Dave
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 16, 2024 at 11:16 AM Yifan Cai <yc25c...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> "WITH ALL" seems to be a natural addition to the directives.
>>>>>>>>>>> What do you think about adding the fifth keyword ALL to retain all
>>>>>>>>>>> fields
>>>>>>>>>>> of the table schema?
>>>>>>>>>>>
>>>>>>>>>>> For instance, CREATE TABLE new_table LIKE original_table WITH
>>>>>>>>>>> ALL, it replicates options, indexes, triggers, constraints and any
>>>>>>>>>>> applicable kinds that are introduced in the future.
>>>>>>>>>>>
>>>>>>>>>>> - Yifan
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 16, 2024 at 7:46 AM guo Maxwell <
>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Disscussed with Bernardo on slack，and +1 with his advice on
>>>>>>>>>>> adding a fourth keyword.
>>>>>>>>>>>
>>>>>>>>>>> The keyword would be CONSTRAINTS ， any more suggestion ？
>>>>>>>>>>>
>>>>>>>>>>> guo Maxwell <cclive1...@gmail.com>于2024年10月16日 周三上午9:55写道：
>>>>>>>>>>>
>>>>>>>>>>> Hi yifan,
>>>>>>>>>>> Thanks for bringing this up. The SELECT permission on the
>>>>>>>>>>> original table is needed. Mysql and PG all have mentioned this, and
>>>>>>>>>>> I also
>>>>>>>>>>> specifically noticed this in my code.
>>>>>>>>>>>
>>>>>>>>>>> I probably missed this in the cep documentation. 😅
>>>>>>>>>>>
>>>>>>>>>>> Yifan Cai <yc25c...@gmail.com> 于2024年10月16日周三 07:46写道：
>>>>>>>>>>>
>>>>>>>>>>> Thanks for creating the CEP! I think it is missing Bernardo's
>>>>>>>>>>> comment on "the need for read permissions on the source table".
>>>>>>>>>>>
>>>>>>>>>>> CreateTableStatement does not check the permissions outside of
>>>>>>>>>>> the enclosing keyspace. Having the SELECT permission on the
>>>>>>>>>>> original table
>>>>>>>>>>> is a requirement for CREATE TABLE LIKE.
>>>>>>>>>>>
>>>>>>>>>>> - Yifan
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Sep 29, 2024 at 11:01 PM guo Maxwell <
>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello, everyone ,
>>>>>>>>>>> I have finished the doc for CEP-43 for CREATE_TABLE_LIKE
>>>>>>>>>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-43++Apache+Cassandra+CREATE+TABLE++LIKE>
>>>>>>>>>>> as
>>>>>>>>>>> said before, looking forward to your suggestions.
>>>>>>>>>>>
>>>>>>>>>>> Štefan Miklošovič <smikloso...@apache.org> 于2024年9月25日周三
>>>>>>>>>>> 03:51写道：
>>>>>>>>>>>
>>>>>>>>>>> I am sorry I do not follow what you mean, maybe an example would
>>>>>>>>>>> help.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Sep 24, 2024 at 6:18 PM guo Maxwell <
>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If there are multiple schema information changes in one ddl
>>>>>>>>>>> statement, will there be schema conflicts in extreme cases?
>>>>>>>>>>> For example, our statement contains both table creation and
>>>>>>>>>>> index creation.
>>>>>>>>>>>
>>>>>>>>>>> guo Maxwell <cclive1...@gmail.com>于2024年9月24日 周二下午8:12写道：
>>>>>>>>>>>
>>>>>>>>>>> +1 on splitting this task and adding the ability to copy tables
>>>>>>>>>>> through different keyspaces in the future.
>>>>>>>>>>>
>>>>>>>>>>> Štefan Miklošovič <smikloso...@apache.org> 于2024年9月23日周一
>>>>>>>>>>> 22:05写道：
>>>>>>>>>>>
>>>>>>>>>>> If we have this table
>>>>>>>>>>>
>>>>>>>>>>> CREATE TABLE ks.tb2 (
>>>>>>>>>>> id int PRIMARY KEY,
>>>>>>>>>>> name text
>>>>>>>>>>> );
>>>>>>>>>>>
>>>>>>>>>>> I can either specify name of an index on my own like this:
>>>>>>>>>>>
>>>>>>>>>>> CREATE INDEX name_index ON ks.tb2 (name) ;
>>>>>>>>>>>
>>>>>>>>>>> or I can let Cassandra to figure that name on its own:
>>>>>>>>>>>
>>>>>>>>>>> CREATE INDEX ON ks.tb2 (name) ;
>>>>>>>>>>>
>>>>>>>>>>> in that case it will name that index "tb2_name_idx".
>>>>>>>>>>>
>>>>>>>>>>> Hence, I would expect that when we do
>>>>>>>>>>>
>>>>>>>>>>> ALTER TABLE ks.to_copy LIKE ks.tb2 WITH INDICES;
>>>>>>>>>>>
>>>>>>>>>>> Then ks.to_copy table will have an index which is called
>>>>>>>>>>> "to_copy_name_idx" without me doing anything.
>>>>>>>>>>>
>>>>>>>>>>> For types, we do not need to do anything when we deal with the
>>>>>>>>>>> same keyspace. For simplicity, I mentioned that we might deal with
>>>>>>>>>>> the same
>>>>>>>>>>> keyspace scenario only for now and iterate on that in the future.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Sep 23, 2024 at 8:53 AM guo Maxwell <
>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello everyone,
>>>>>>>>>>>
>>>>>>>>>>> Cep is being written, and I encountered some problems during the
>>>>>>>>>>> process. I would like to discuss them with you. If you read the
>>>>>>>>>>> description
>>>>>>>>>>> of this CASSANDRA-7662
>>>>>>>>>>> <https://issues.apache.org/jira/browse/CASSANDRA-7662>, we will
>>>>>>>>>>> find that initially the original creator of this jira did not
>>>>>>>>>>> intend to
>>>>>>>>>>> implement structural copying of indexes, views, and triggers only
>>>>>>>>>>> the
>>>>>>>>>>> column and its data type.
>>>>>>>>>>>
>>>>>>>>>>> However, after investigating some db related syntax and function
>>>>>>>>>>> implementation, I found that it may be necessary for us to provide
>>>>>>>>>>> some
>>>>>>>>>>> rich syntax to support the replication of indexes, views, etc.
>>>>>>>>>>>
>>>>>>>>>>> In order to support selective copy of the basic structure of the
>>>>>>>>>>> table (columns and types), table options, table-related indexes,
>>>>>>>>>>> views,
>>>>>>>>>>> triggers, etc. We need some new syntax, it seems that the syntax of
>>>>>>>>>>> pg is
>>>>>>>>>>> relatively comprehensive, it use the keyword INCLUDING/EXCLUDING to
>>>>>>>>>>> flexibly control the removal and retention of indexes, table
>>>>>>>>>>> information,
>>>>>>>>>>> etc. see pg create table like
>>>>>>>>>>> <https://www.postgresql.org/docs/8.1/sql-createtable.html> ,
>>>>>>>>>>> the new created index name is different from the original table's
>>>>>>>>>>> index
>>>>>>>>>>> name , seenewly copied index names are different from original
>>>>>>>>>>> <https://github.com/postgres/postgres/blob/master/doc/src/sgml/ref/create_table.sgml#L749>
>>>>>>>>>>> , the name is based on some rule.
>>>>>>>>>>> Mysql is relatively simple and copies columns and indexes by
>>>>>>>>>>> default. see mysql create table like
>>>>>>>>>>> <https://dev.mysql.com/doc/refman/8.4/en/create-table-like.html>
>>>>>>>>>>> and the newly created index name is the same with the original
>>>>>>>>>>> table's
>>>>>>>>>>> index name.
>>>>>>>>>>>
>>>>>>>>>>> So for Casandra, I hope it can also support the information copy
>>>>>>>>>>> of index and even view/trigger. And I also hope to be able to
>>>>>>>>>>> flexibly
>>>>>>>>>>> decide which information is copied like pg.
>>>>>>>>>>>
>>>>>>>>>>> Besides, I think the copy can happen between different
>>>>>>>>>>> keyspaces. And UDT needs to be taken into account.
>>>>>>>>>>>
>>>>>>>>>>> But as we know the index/view/trigger name are all under
>>>>>>>>>>> keyspace level, so it seems that the newly created index name (or
>>>>>>>>>>> view
>>>>>>>>>>> name/ trigger name) must be different from the original tables'
>>>>>>>>>>> ,otherwise
>>>>>>>>>>> names would clash .
>>>>>>>>>>>
>>>>>>>>>>> So regarding the above problem, one idea I have is that for
>>>>>>>>>>> newly created types, indexes and views under different keyspaces
>>>>>>>>>>> and the
>>>>>>>>>>> same keyspace, we first generate random names for them, and then we
>>>>>>>>>>> can add
>>>>>>>>>>> the ability of modifying the names(for
>>>>>>>>>>> types/indexes/views/triggers) so
>>>>>>>>>>> that users can manually change the names.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> guo Maxwell <cclive1...@gmail.com> 于2024年9月20日周五 08:06写道：
>>>>>>>>>>>
>>>>>>>>>>> No，I think still need some discuss on grammar detail after I
>>>>>>>>>>> finish the first version
>>>>>>>>>>>
>>>>>>>>>>> Patrick McFadin <pmcfa...@gmail.com>于2024年9月20日 周五上午2:24写道：
>>>>>>>>>>>
>>>>>>>>>>> Is this CEP ready for a VOTE thread?
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Aug 24, 2024 at 8:56 PM guo Maxwell <
>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thank you for your replies, I will prepare a CEP later.
>>>>>>>>>>>
>>>>>>>>>>> Patrick McFadin <pmcfa...@gmail.com> 于2024年8月20日周二 02:11写道：
>>>>>>>>>>>
>>>>>>>>>>> +1 This is a CEP
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Aug 19, 2024 at 10:50 AM Jon Haddad <j...@jonhaddad.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Given the fairly large surface area for this, i think it should
>>>>>>>>>>> be a CEP.
>>>>>>>>>>>
>>>>>>>>>>> —
>>>>>>>>>>> Jon Haddad
>>>>>>>>>>> Rustyrazorblade Consulting
>>>>>>>>>>> rustyrazorblade.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Aug 19, 2024 at 10:44 AM Bernardo Botella <
>>>>>>>>>>> conta...@bernardobotella.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Definitely a nice addition to CQL.
>>>>>>>>>>>
>>>>>>>>>>> Looking for inspiration at how Postgres and Mysql do that may
>>>>>>>>>>> also help with the final design (I like the WITH proposed by
>>>>>>>>>>> Stefan, but I
>>>>>>>>>>> would definitely take a look at the INCLUDING keyword proposed by
>>>>>>>>>>> Postgres).
>>>>>>>>>>> https://www.postgresql.org/docs/current/sql-createtable.html
>>>>>>>>>>> https://dev.mysql.com/doc/refman/8.4/en/create-table-like.html
>>>>>>>>>>>
>>>>>>>>>>> On top of that, and as part of the interesting questions, I
>>>>>>>>>>> would like to add the permissions to the mix. Both the question
>>>>>>>>>>> about
>>>>>>>>>>> copying them over (with a WITH keyword probably), and the need for
>>>>>>>>>>> read
>>>>>>>>>>> permissions on the source table as well.
>>>>>>>>>>>
>>>>>>>>>>> Bernardo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Aug 19, 2024, at 10:01 AM, Štefan Miklošovič <
>>>>>>>>>>> smikloso...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> BTW this would be cool to do as well:
>>>>>>>>>>>
>>>>>>>>>>> ALTER TABLE ks.to_copy LIKE ks.tb WITH INDICES;
>>>>>>>>>>>
>>>>>>>>>>> This would mean that if we create a copy of a table, later we
>>>>>>>>>>> can decide that we need indices too, so we might "enrich" that
>>>>>>>>>>> table with
>>>>>>>>>>> indices from the old one without necessarily explicitly re-creating
>>>>>>>>>>> them on
>>>>>>>>>>> that new table.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Aug 19, 2024 at 6:55 PM Štefan Miklošovič <
>>>>>>>>>>> smikloso...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I think this is an interesting idea worth exploring. I
>>>>>>>>>>> definitely agree with Benjamin who raised important questions which
>>>>>>>>>>> needs
>>>>>>>>>>> to be answered first. Also, what about triggers?
>>>>>>>>>>>
>>>>>>>>>>> It might be rather "easy" to come up with something simple but
>>>>>>>>>>> it should be a comprehensive solution with predictable behavior we
>>>>>>>>>>> all
>>>>>>>>>>> agree on.
>>>>>>>>>>>
>>>>>>>>>>> If a keyspace of a new table does not exist we would need to
>>>>>>>>>>> create that one too before. For the simplicity, I would just make
>>>>>>>>>>> it a must
>>>>>>>>>>> to create it on same keyspace. We might iterate on that in the
>>>>>>>>>>> future.
>>>>>>>>>>>
>>>>>>>>>>> UDTs are created per keyspace so there is nothing to re-create.
>>>>>>>>>>> We just need to reference it from a new table, right?
>>>>>>>>>>>
>>>>>>>>>>> Indexes and MVs are interesting but in theory they might be
>>>>>>>>>>> re-created too.
>>>>>>>>>>>
>>>>>>>>>>> Would it be appropriate to use something like this?
>>>>>>>>>>>
>>>>>>>>>>> CREATE TABLE ks.tb_copy LIKE ks.tb WITH INDEXES AND VIEWS AND
>>>>>>>>>>> TRIGGERS ....
>>>>>>>>>>>
>>>>>>>>>>> Without "WITH" it would just copy a table with nothing else.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Aug 19, 2024 at 6:10 PM guo Maxwell <
>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello， everyone：
>>>>>>>>>>> As Jira CASSANDRA-7662
>>>>>>>>>>> <https://issues.apache.org/jira/browse/CASSANDRA-7662> has
>>>>>>>>>>> described , we would like to introduce a new grammer " CREATE TABLE
>>>>>>>>>>> LIKE "
>>>>>>>>>>> ,which simplifies creating new tables duplicating the existing
>>>>>>>>>>> ones .
>>>>>>>>>>> The format may be like : CREATE TABLE <new_table> LIKE
>>>>>>>>>>> <old_table>
>>>>>>>>>>> Before I implement this function, do you have any suggestions on
>>>>>>>>>>> this?
>>>>>>>>>>>
>>>>>>>>>>> Looking forward to your reply！
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> -Dave
>>>>>>>>>>>
>>>>>>>>>>> David A. Herrington II
>>>>>>>>>>> President and Chief Engineer
>>>>>>>>>>> RhinoSource, Inc.
>>>>>>>>>>>
>>>>>>>>>>> *Data Lake Architecture, Cloud Computing and Advanced Analytics.*
>>>>>>>>>>>
>>>>>>>>>>> www.rhinosource.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> -Dave
>>>>>>>>>>>
>>>>>>>>>>> David A. Herrington II
>>>>>>>>>>> President and Chief Engineer
>>>>>>>>>>> RhinoSource, Inc.
>>>>>>>>>>>
>>>>>>>>>>> *Data Lake Architecture, Cloud Computing and Advanced Analytics.*
>>>>>>>>>>>
>>>>>>>>>>> www.rhinosource.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> -Dave
>>>>>>>>>>>
>>>>>>>>>>> David A. Herrington II
>>>>>>>>>>> President and Chief Engineer
>>>>>>>>>>> RhinoSource, Inc.
>>>>>>>>>>>
>>>>>>>>>>> *Data Lake Architecture, Cloud Computing and Advanced Analytics.*
>>>>>>>>>>>
>>>>>>>>>>> www.rhinosource.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> -Dave
>>>>>>>>>>>
>>>>>>>>>>> David A. Herrington II
>>>>>>>>>>> President and Chief Engineer
>>>>>>>>>>> RhinoSource, Inc.
>>>>>>>>>>>
>>>>>>>>>>> *Data Lake Architecture, Cloud Computing and Advanced Analytics.*
>>>>>>>>>>>
>>>>>>>>>>> www.rhinosource.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
