Github user fhueske commented on the issue:

    https://github.com/apache/flink/pull/3829
  
    Hi @lincoln-lil, that's very good input!
    
    What do you think about the following? We keep the current `TableSink` 
interface, but when registering a `TableSink` in a `TableEnvironment` we 
request field types (and optionally field names). Internally, the 
`TableEnvironment` calls `configure()` and stores the returned configured copy 
of the `TableSink` in the catalog. This would have the benefits that
    - we use the existing interface in a clean way and only need to update the 
documentation to explain both modes to use the interface.
    - the same `TableSink` implementation can be used with eager and lazy 
schema registration.
    
    I agree with your proposal for `writeToSink` and `insertInto`. So the 
method signature would be `Table.insertInto(tableSink: String, config: 
QueryConfig): Unit`, where `tableSink` would be the name of a registered 
`TableSink`.
    
    Regarding the names of the methods I'm not sure how well-known the 
distinction of `SQL`, `DML` and `DDL` is. You are of course right that `SELECT` 
and `INSERT` are part of `DML` (but also part of SQL which is the superset of 
`DML` and `DDL`). 
    
    I think SQL is just better known than `DML` and many users might not be 
know what `DML` means.
    I'd propose the following two methods:
    - `sqlInsert(query: String, config: QueryConfig): Unit` and 
    - `sqlSelect(query: String): Table` (we can add `sqlSelect` and deprecate 
`sql`).
    
    Does that make sense to you?
    Best, Fabian


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to