Hi Jingsong,
I added a short description for the options:
* CONSTRAINTS: primary keys, unique key, does not include NOT NULL
constraint (in Flink it's part of the type)
* GENERATED: computed columns
* OPTIONS: connector properties in WITH (...) clause
I think partitions are a valid
Hi Dawid,
Just two small questions:
- Can you explain more about "CONSTRAINTS, GENERATED, OPTIONS" in the FLIP?
I can image the meaning of "CONSTRAINTS, OPTIONS" in the example, but it is
hard to guess "GENERATED".
- Which category does partition keys belong to?
(I am sorry if I've disturbed the
Hi Timo,
I think your suggestion makes sense. I updated the document.
As there are no more comments I will start a vote for it.
Best,
Dawid
On 30/03/2020 16:40, Timo Walther wrote:
> Hi Dawid,
>
> thanks for updating the FLIP. One minor comment from my side, should
> we move the LIKE clause
Hi Dawid,
thanks for updating the FLIP. One minor comment from my side, should we
move the LIKE clause to the very end?
CREATE TABLE X () WITH () LIKE ...
Otherwise, the LIKE clause looks a bit lost if there are options
afterwards. Otherwise, +1 for start a vote from my side.
Regards,
Thank you for your opinions. I updated the FLIP with results of the
discussion. Let me know if you have further concerns.
Best,
Dawid
On 05/03/2020 07:46, Jark Wu wrote:
> Hi Dawid,
>
>> INHERITS creates a new table with a "link" to the original table.
> Yes, INHERITS is a "link" to the
Hi Dawid,
thanks for your design document.
LIKE vs. INHERITS:
I would also not start creating transitive dependencies for table
metadata. This is very complicated to maintain in a long-term, esp. when
we ALTER or DELETE a table. Instead the new table metadata should be
materialized
+1 to use LIKE and put after schema part.
I also prefer the keyword LIKE than INHERITS, because it's easier to type
and understand, for a non-native English user :)
But I would like to limit a single LIKE clause in the DDL in the first
version. We can allow multiple LIKE clause in the future if
Sorry for a late reply, but I was on vacation.
As for putting the LIKE after the schema part. You're right, sql
standard lets it be only in the schema part. I was mislead by examples
for DB2 and MYSQL, which differ from the standard in that respect. My
bad, sorry.
Nevertheless I'd still be in
Hi Dawid,
> INHERITS creates a new table with a "link" to the original table.
Yes, INHERITS is a "link" to the original table in PostgreSQL.
But INHERITS is not SQL standard, I think it's fine for vendors to define
theire semantics.
> Standard also allows declaring the clause after the schema
Thanks Dawid for starting this discussion.
I like the "LIKE".
1.For "INHERITS", I think this is a good feature too, yes, ALTER TABLE will
propagate any changes in column data definitions and check constraints down
the inheritance hierarchy. A inherits B, A and B share every things, they
have the
Hi Jark,
I did investigate the INHERITS clause, but it has a semantic that in my
opinion we definitely don't want to support. INHERITS creates a new table
with a "link" to the original table. Therefore if you e.g change the schema
of the original table it's also reflected in the child table. It's
Hi Dawid,
Thanks for starting this discussion. I like the idea.
Once we support more intergrated catalogs,
e.g. ConfluentSchemaRegistryCatalog, this problem will be more urgent.
Because it's very common to adjust existing tables in catalog slightly.
My initial thought was introducing INHERITS
Hi devs,
I wanted to bring another improvement proposal up for a discussion.
Often users need to adjust existing tables slightly. This is especially
useful when users need to enhance a table created from an external tool
(e.g. HIVE) with Flink's specific information such as e.g watermarks. It
can
13 matches
Mail list logo
