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 comp
People who are OK with vars in tests - are you also the ones who are going
to write vars from now on yourself or you just do not mind if you encounter
it?
There is a difference between
"keep it in tests, I am going to use this, this is actually a good idea"
and
"keep it in tests if people are g
Hi,
I don’t like `var` anywhere. Even if IntelliJ could automatically insert the
concrete type it would still be a problem in the GH compare view. GH compare
view is a real problem, because any time something is sufficiently obfuscated I
have to bounce back and forth with an IDE, check out the
My comment comes from the fact that I find it counter intuitive to have
constraints defined at column level that reference other columns. From your
example, referencing column b from the column a definition looks off in my
head. Besides, validation can become trickier. For instance, when validat
Could you give some concrete examples of potential problems when
introducing general / cross column constraints?
When I have a table where I do not want two columns to contain the same
values for a given primary key (and we do not want to deal with a tuple as
suggested before), why would this not
Hi everyone,
Thanks a lot for the constructive discussion! Sorry for coming to it so late in
the game, I’ve been out this past week, but I’m back up and running.
Really interesting ideas. So, to recap:
I do agree that we can keep out from initial implementations the Cross Column
Constraints. T
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' : 'LeveledCompactionStrat
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 bein
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
