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！ >>>>>> >>>>> >>>>
