Any update on this ?If there are no updates, I wonder if we can start a new
update on the VOTE thread.
guo Maxwell <cclive1...@gmail.com> 于2024年11月5日周二 19:23写道：
> Hello, everyone.
> I have a point of view that our CREATE TABLE LIKE grammar should not
> support the setting of table options, like :
>
>> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name WITH
>> TRIGGERS AND VIEWS AND compaction = { 'class' : 'LeveledCompactionStrategy'
>> } AND default_time_to_live = 86400;
>
> If the user wants to copy the table and set the compaction strategy for
> the new table, then he can execute the
> ALTER TABLE statement after copying the table.
>
> So, I think it’s enough to support the above five cases . The original
> intention of copying a table is to copy the table,
> and support what is to or not to copy during the copying process. Not
> changing the options at the same time.
>
> WDYT ?
>
> guo Maxwell <cclive1...@gmail.com> 于2024年11月5日周二 14:07写道：
>
>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
