[
https://issues.apache.org/jira/browse/FLINK-21532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17292727#comment-17292727
]
Jark Wu commented on FLINK-21532:
---------------------------------
I think this depends the implementation of catalog.
I just checked the implementation of {{HiveCatalog}}, it uses
{{CatalogTable#getOptions}} to serialize the options instead of calling
{{CatalogTableImpl#toProperties}}. Thus, Hive is case-sensitive now and
changing {{CatalogTableImpl#toProperties}} doesn't affect Hive catalog.
cc [~lirui]
I also asked [~kaibo.zhou], and confirmed it doesn't affect the VVP catalog.
> Make CatalogTableImpl#toProperties and CatalogTableImpl#fromProperties case
> sensitive
> -------------------------------------------------------------------------------------
>
> Key: FLINK-21532
> URL: https://issues.apache.org/jira/browse/FLINK-21532
> Project: Flink
> Issue Type: Improvement
> Components: Table SQL / API
> Reporter: Lsw_aka_laplace
> Priority: Major
>
> For now, both legacy Table/SQL API and implementation and current Table/SQL
> API and implementation are case sensitive when it comes to the key of table
> properties. Though it is highly recommended to be full of low case, key in
> upper case still works well.
> But the following case upon current code seems a little misleading..
> Given a Ddl sql:
> """
> create table a (f string) with ('K1' = 'xxx')
> """
> The property of corresponding `CatalogTableImpl` is Map(K1->xxx).
> After calling `CatalogTableImpl#toProperties` and then
> `CatalogTableImpl#fromProperties`, there comes a `CatalogTableImpl` with
> properity:Map(k1->xxx). The letter in upper case has been converted into low
> case.
>
> After reading code, the reason seems that the two method mentioned above
> normalize key by default and can not be configured.
>
> As far as I'm concerned, There is an easy way that just `
> DescriptorProperties descriptorProperties = new DescriptorProperties(false)`,
> when means not to normalize key to low case.
>
> While, for the fear that this should break some underlying rules and cause
> some unexpected incompatibility. This part shall be under well discussed.
> What's more, a better alternate way is welcomed~
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
