[VOTE] Release Apache Cassandra 5.0.2

[Mick Semb Wever]

Proposing the test build of Cassandra 5.0.2 for release.

sha1: f278f6774fc76465c182041e081982105c3e7dbb
Git: https://github.com/apache/cassandra/tree/5.0.2-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1349/org/apache/cassandra/cassandra-all/5.0.2/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/5.0.2/

The vote will be open for 72 hours (longer if needed). Everyone who has
tested the build is invited to vote. Votes by PMC members are considered
binding. A vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt:
https://github.com/apache/cassandra/blob/5.0.2-tentative/CHANGES.txt
[2]: NEWS.txt:
https://github.com/apache/cassandra/blob/5.0.2-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 5.0.2

[C. Scott Andreas]

+1. CASSANDRA-19989 and CASSANDRA-19968 will be good fixes to get out. On Oct 16, 
2024, at 5:20 AM, Mick Semb Wever  wrote: Proposing the test 
build of Cassandra 5.0.2 for release. sha1: f278f6774fc76465c182041e081982105c3e7dbb 
Git: https://github.com/apache/cassandra/tree/5.0.2-tentative Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1349/org/apache/cassandra/cassandra-all/5.0.2/
 The Source and Build Artifacts, and the Debian and RPM packages and repositories, 
are available here: https://dist.apache.org/repos/dist/dev/cassandra/5.0.2/ The vote 
will be open for 72 hours (longer if needed). Everyone who has tested the build is 
invited to vote. Votes by PMC members are considered binding. A vote passes if there 
are at least three binding +1s and no -1's. [1]: CHANGES.txt: 
https://github.com/apache/cassandra/blob/5.0.2-tentative/CHANGES.txt [2]: NEWS.txt: 
https://github.com/apache/cassandra/blob/5.0.2-tentative/NEWS.txt

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[guo Maxwell]

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 于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  于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 
>> wrote:
>>
>>> Hello, everyone ,
>>> I have finished the doc for CEP-43 for CREATE_TABLE_LIKE
>>> 
>>>  as
>>> said before, looking forward to your suggestions.
>>>
>>> Štefan Miklošovič  于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 
 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 于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č  于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 
>>> 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
 , 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
  , the
 new created index name is different from the original table's index 
 name ,
 seenewly copied index names are different from original
 
 , the name is based on some rule.
 Mysql is relatively simple and copies columns and indexes by
 default. see mysql create table like
 
 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.
 

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Dave Herrington]

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  wrote:

> To yifan :
> At the beginning of the period, I also thought about adding the keyword
> ALL, refer to pg
>  , 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
> 
> .
>
>
> Patrick McFadin  于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 
>> 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  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 
 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 于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  于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 
>>> wrote:
>>>
 Hello, everyone ,
 I have finished the doc for CEP-43 for CREATE_TABLE_LIKE
 
  as
 said before, looking forward to your suggestions.

 Štefan Miklošovič  于2024年9月25日周三 03:51写道：

> I am sorry I do not follow what you mean, maybe an example would

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Dave Herrington]

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  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  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 于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  于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 
 wrote:

> Hello, everyone ,
> I have finished the doc for CEP-43 for CREATE_TABLE_LIKE
> 
>  as
> said before, looking forward to your suggestions.
>
> Štefan Miklošovič  于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 
>> 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 于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č  于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 
> 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
>> , 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 

Re: [VOTE] Release Apache Cassandra 5.0.2

[Ekaterina Dimitrova]

+1

On Thu, 17 Oct 2024 at 0:46, David Capwell  wrote:

> +1
>
>
> On Oct 16, 2024, at 2:45 PM, Dinesh Joshi  wrote:
>
> +1
>
> On Wed, Oct 16, 2024 at 5:19 AM Mick Semb Wever  wrote:
>
>> Proposing the test build of Cassandra 5.0.2 for release.
>>
>> sha1: f278f6774fc76465c182041e081982105c3e7dbb
>> Git: https://github.com/apache/cassandra/tree/5.0.2-tentative
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1349/org/apache/cassandra/cassandra-all/5.0.2/
>>
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/5.0.2/
>>
>> The vote will be open for 72 hours (longer if needed). Everyone who has
>> tested the build is invited to vote. Votes by PMC members are considered
>> binding. A vote passes if there are at least three binding +1s and no -1's.
>>
>> [1]: CHANGES.txt:
>> https://github.com/apache/cassandra/blob/5.0.2-tentative/CHANGES.txt
>> [2]: NEWS.txt:
>> https://github.com/apache/cassandra/blob/5.0.2-tentative/NEWS.txt
>>
>
>

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[guo Maxwell]

To yifan :
At the beginning of the period, I also thought about adding the keyword
ALL, refer to pg
 , 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

.


Patrick McFadin  于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 
> 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  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 
>>> 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 于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  于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 
>> wrote:
>>
>>> Hello, everyone ,
>>> I have finished the doc for CEP-43 for CREATE_TABLE_LIKE
>>> 
>>>  as
>>> said before, looking forward to your suggestions.
>>>
>>> Štefan Miklošovič  于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 
 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 于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č  于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) ;
>>

Re: [VOTE] Release Apache Cassandra 5.0.2

[Dinesh Joshi]

+1

On Wed, Oct 16, 2024 at 5:19 AM Mick Semb Wever  wrote:

> Proposing the test build of Cassandra 5.0.2 for release.
>
> sha1: f278f6774fc76465c182041e081982105c3e7dbb
> Git: https://github.com/apache/cassandra/tree/5.0.2-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1349/org/apache/cassandra/cassandra-all/5.0.2/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/5.0.2/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/5.0.2-tentative/CHANGES.txt
> [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/5.0.2-tentative/NEWS.txt
>

Re: [VOTE] Release Apache Cassandra 5.0.2

[David Capwell]

+1

> On Oct 16, 2024, at 2:45 PM, Dinesh Joshi  wrote:
> 
> +1
> 
> On Wed, Oct 16, 2024 at 5:19 AM Mick Semb Wever  > wrote:
>> Proposing the test build of Cassandra 5.0.2 for release.
>> 
>> sha1: f278f6774fc76465c182041e081982105c3e7dbb
>> Git: https://github.com/apache/cassandra/tree/5.0.2-tentative
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1349/org/apache/cassandra/cassandra-all/5.0.2/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and 
>> repositories, are available here: 
>> https://dist.apache.org/repos/dist/dev/cassandra/5.0.2/
>> 
>> The vote will be open for 72 hours (longer if needed). Everyone who has 
>> tested the build is invited to vote. Votes by PMC members are considered 
>> binding. A vote passes if there are at least three binding +1s and no -1's.
>> 
>> [1]: CHANGES.txt: 
>> https://github.com/apache/cassandra/blob/5.0.2-tentative/CHANGES.txt
>> [2]: NEWS.txt: 
>> https://github.com/apache/cassandra/blob/5.0.2-tentative/NEWS.txt

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Yifan Cai]

"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  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 于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  于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 
>>> wrote:
>>>
 Hello, everyone ,
 I have finished the doc for CEP-43 for CREATE_TABLE_LIKE
 
  as
 said before, looking forward to your suggestions.

 Štefan Miklošovič  于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 
> 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 于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č  于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 
 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
> , 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
>  , the
> new created index name is different from the original table's index 
> name ,
> seenewly copied index names are different from original
> 
> , the name is based on some rule.
> Mysql is relatively simple and copies columns an

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Patrick McFadin]

+1 That makes much more sense in my experience.

On Wed, Oct 16, 2024 at 12:12 PM Dave Herrington 
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  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  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 于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  于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 
> wrote:
>
>> Hello, everyone ,
>> I have finished the doc for CEP-43 for CREATE_TABLE_LIKE
>> 
>>  as
>> said before, looking forward to your suggestions.
>>
>> Štefan Miklošovič  于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 
>>> 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 于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č  于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 
>> 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
>>> , 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, t