You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by buptljy <gi...@git.apache.org> on 2018/03/02 05:32:36 UTC
[GitHub] flink pull request #5615: [FLINK-6895][table]Add STR_TO_DATE supported in SQ...
GitHub user buptljy opened a pull request:
https://github.com/apache/flink/pull/5615
[FLINK-6895][table]Add STR_TO_DATE supported in SQL
## What is the purpose of the change
Add STR_TO_DATE Function supported in SQL
## Brief change log
* STR_TO_DATE(str string, format string)
\- str is the string that need to be transformed.
\- format is the pattern of "str"
* Add tests in ScalarFunctionsTest.scala
* Add docs in sql.md
## Verifying this change
* Run unit tests in ScalarFunctionsTest.scala
## Does this pull request potentially affect one of the following parts:
* A new sql function
## Documentation
* Add docs in sql.md
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/buptljy/flink master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/flink/pull/5615.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5615
----
commit 59752143ee438cb11969ae4bdda1fac5fc32813c
Author: Liao Jiayi <li...@...>
Date: 2018-03-01T11:58:08Z
add str_to_date sql function
commit 63f71e4b3d6378f2114aa04ba4d1128f1ec3bc38
Author: Liao Jiayi <li...@...>
Date: 2018-03-01T11:58:41Z
Merge branch 'master' of github.com:apache/flink
----
---
[GitHub] flink pull request #5615: [FLINK-6895][table]Add STR_TO_DATE supported in SQ...
Posted by buptljy <gi...@git.apache.org>.
Github user buptljy closed the pull request at:
https://github.com/apache/flink/pull/5615
---
[GitHub] flink issue #5615: [FLINK-6895][table]Add STR_TO_DATE supported in SQL
Posted by buptljy <gi...@git.apache.org>.
Github user buptljy commented on the issue:
https://github.com/apache/flink/pull/5615
Actually I am not sure if it is appropriate to return "string" because it should be the inverse of the "DATE_FORMAT()". However, If I return DATE/TIME/DATETIME as the jira issue described, the type of data user receives will be uncertain in one of DATE/TIME/DATETIME.
Do you have some good ideas ? I will optimize it.
---