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

Reply via email to