[SPARK-28137][SQL] Data Type Formatting Functions: `to_number` #35060

beliefer · 2021-12-29T12:54:50Z

What changes were proposed in this pull request?

Many database support the function to_number to convert a string to number.
The implement of to_number has many different between Postgresql ,Oracle and Phoenix.
So, this PR follows the implement of to_number in Oracle that give a strict parameter verification.
So, this PR follows the implement of to_number in Phoenix that uses BigDecimal.

This PR support the patterns for numeric formatting as follows:

Pattern	Description
9	digit position
0	digit position
. (period)	decimal point (only allowed once)
, (comma)	group (thousands) separator
S	sign anchored to number (only allowed once)
$	value with a leading dollar sign (only allowed once)
D	decimal point (only allowed once)
G	group (thousands) separator

There are some mainstream database support the syntax.
PostgreSQL:
https://www.postgresql.org/docs/12/functions-formatting.html

Oracle:
https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/TO_NUMBER.html#GUID-D4807212-AFD7-48A7-9AED-BEC3E8809866

Vertica
https://www.vertica.com/docs/10.0.x/HTML/Content/Authoring/SQLReferenceManual/Functions/Formatting/TO_NUMBER.htm?tocpath=SQL%20Reference%20Manual%7CSQL%20Functions%7CFormatting%20Functions%7C_____7

Redshift
https://docs.aws.amazon.com/redshift/latest/dg/r_TO_NUMBER.html

DB2
https://www.ibm.com/support/knowledgecenter/SSGU8G_14.1.0/com.ibm.sqls.doc/ids_sqs_1544.htm

Teradata
https://docs.teradata.com/r/kmuOwjp1zEYg98JsB8fu_A/TH2cDXBn6tala29S536nqg

Snowflake:
https://docs.snowflake.net/manuals/sql-reference/functions/to_decimal.html

Exasol
https://docs.exasol.com/sql_references/functions/alphabeticallistfunctions/to_number.htm#TO_NUMBER

Phoenix
http://phoenix.incubator.apache.org/language/functions.html#to_number

Singlestore
https://docs.singlestore.com/v7.3/reference/sql-reference/numeric-functions/to-number/

Intersystems
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RSQL_TONUMBER

The syntax like:

select to_number('12,454.8-', '99G999D9S');
-12454.8

Why are the changes needed?

to_number is very useful for formatted currency to number conversion.

Does this PR introduce any user-facing change?

Yes. New feature.

How was this patch tested?

New tests

cloud-fan · 2021-12-30T09:23:40Z

...alyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/numberFormatExpressions.scala

+         '.':  decimal point (only allowed once)
+         ',':  group (thousands) separator
+         'S':  sign anchored to number (uses locale)
+         'D':  decimal point (uses locale)


is it true? We simply relace D with ., and I don't see we handle locale there.

Please see https://github.com/apache/spark/blob/5cfb5dfde5e566a4380def46324034604012af32/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberUtils.scala#L172

I only see that we replace D with . during normalization.

This comment references PostgreSQL and Oracle. But other database does not mention locale.
I guess NumberFormat.getNumberInstance(Locale.ROOT) is enough.

the Spark doc should match Spark implementation

cloud-fan · 2021-12-30T09:25:28Z

...alyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/numberFormatExpressions.scala

+     _FUNC_(strExpr, formatExpr) - Convert `strExpr` to a number based on the `formatExpr`.
+       The format can consist of the following characters:
+         '9':  digit position (can be dropped if insignificant)
+         '0':  digit position (will not be dropped, even if insignificant)


I think we need more documents. I still don't understand the difference between 0 and 9 after reading this.

I updated some comment. Please review again.

to_number is a parsing function, I think 0 and 9 have no difference?

Then why do we document them differently here?

Then why do we document them differently here?

Updated

cloud-fan · 2021-12-30T09:26:41Z

...alyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/numberFormatExpressions.scala

+    if (inputTypeCheck.isSuccess) {
+      if (right.foldable) {
+        if (builder.normalizedNumberFormat.length == 0) {
+          TypeCheckResult.TypeCheckFailure(s"Format expression cannot be empty")


can we do this check in builder.check()?

cloud-fan · 2021-12-30T09:29:20Z

...alyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/numberFormatExpressions.scala

+      boolean ${ev.isNull} = ${eval.isNull};
+      ${CodeGenerator.javaType(dataType)} ${ev.value} = ${CodeGenerator.defaultValue(dataType)};
+      if (!${ev.isNull}) {
+        $builderClass $builder = new $builderClass("$numberFormat");


It's pretty risky to embed user input in the generated code, as people can inject malicious code.

We should do ctx.addReferenceObj(builder)

cloud-fan · 2022-01-04T05:31:15Z

...alyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/numberFormatExpressions.scala

+     _FUNC_(strExpr, formatExpr) - Convert `strExpr` to a number based on the `formatExpr`.
+       The format can consist of the following characters:
+         '9':  digit position
+         '0':  digit position too


'0' or '9': digit position

cloud-fan · 2022-01-06T14:40:02Z

docs/sql-ref-number-pattern.md

+
+|Symbol|Meaning|Examples|
+|------|-------|--------|
+|**9**|digit position (can be dropped if insignificant)|9999|


I noticed that snowflake does not simply trim the leading/trailing zeros, but replace them with spaces. Is it a common behavior in other databases?

docs/sql-ref-number-pattern.md

cloud-fan · 2022-01-06T14:42:34Z

docs/sql-ref-number-pattern.md

+|**D**|decimal point (only allowed once)|99D99|
+|**,**|group (thousands) separator|9,999|
+|**G**|group (thousands) separator|9G999|
+|**-**|sign anchored to number|-9999|


this is also only allowed once?

PostgreSQL throws ERROR: cannot use "S" twice
Oracle throws ORA-01481: 无效的数字格式模型.

cloud-fan · 2022-01-06T14:45:12Z

docs/sql-ref-number-pattern.md

+
+Usage notes for numeric formatting:
+
+- 0 specifies a digit position that will always be printed, even if it contains a leading/trailing zero. 9 also specifies a digit position, but if it is a leading zero then it will be replaced by a space, while if it is a trailing zero and fill mode is specified then it will be deleted. (For to_number(), these two pattern characters are equivalent.)


Although to_char is not implemented yet, can we use to_char as an example to demonstrate the differences between 0 and 9?

cloud-fan · 2022-01-06T14:45:40Z

docs/sql-ref-number-pattern.md

+
+- 0 specifies a digit position that will always be printed, even if it contains a leading/trailing zero. 9 also specifies a digit position, but if it is a leading zero then it will be replaced by a space, while if it is a trailing zero and fill mode is specified then it will be deleted. (For to_number(), these two pattern characters are equivalent.)
+
+- The pattern characters S, D, and G represent the sign, decimal point, and thousands separator characters. The pattern characters period and comma represent those exact characters, with the meanings of decimal point and thousands separator.


This doesn't say anything. Can we remove it?

cloud-fan · 2022-01-06T14:46:14Z

docs/sql-ref-number-pattern.md

+|**9**|digit position (can be dropped if insignificant)|9999|
+|**0**|digit position (will not be dropped, even if insignificant)|0999|
+|**.**|decimal point (only allowed once)|99.99|
+|**D**|decimal point (only allowed once)|99D99|


Suggested change

|**D**|decimal point (only allowed once)|99D99|

|**D**|decimal point, same as **.** (only allowed once)|99D99|

cloud-fan · 2022-01-06T14:46:35Z

docs/sql-ref-number-pattern.md

+|**.**|decimal point (only allowed once)|99.99|
+|**D**|decimal point (only allowed once)|99D99|
+|**,**|group (thousands) separator|9,999|
+|**G**|group (thousands) separator|9G999|


Suggested change

|**G**|group (thousands) separator|9G999|

|**G**|group (thousands) separator, same as **,**|9G999|

cloud-fan · 2022-01-10T12:54:58Z

...alyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/numberFormatExpressions.scala

+  usage = """
+     _FUNC_(strExpr, formatExpr) - Convert `strExpr` to a number based on the `formatExpr`.
+       The format can consist of the following characters:
+         '0' or '9': digit position


Suggested change

'0' or '9': digit position

'0' or '9': digit position

cloud-fan · 2022-01-10T12:55:17Z

...alyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/numberFormatExpressions.scala

+         '0' or '9': digit position
+         '.' or 'D':  decimal point (only allowed once)
+         ',' or 'G':  group (thousands) separator
+         '-' or 'S':  sign anchored to number


is it only allowed once?

PostgreSQL throws ERROR: cannot use "S" twice
Oracle throws ORA-01481: 无效的数字格式模型.

cloud-fan · 2022-01-10T12:59:08Z

...alyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/numberFormatExpressions.scala

+    val builder =
+      ctx.addReferenceObj("builder", numberFormatBuilder, classOf[NumberFormatBuilder].getName)
+    val eval = left.genCode(ctx)
+    ev.copy(code = code"""


nit: use multi-line string.

code""" |... """.stripMargin

cloud-fan · 2022-01-10T13:01:22Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberUtils.scala

+
+  /**
+   * DecimalFormat provides '#' and '0' as placeholder of digit, ',' as grouping separator,
+   * '.' as decimal separator, '-' as minus, '$' as dollar, but '9', 'G', 'D', 'S'. So we need


Suggested change

* '.' as decimal separator, '-' as minus, '$' as dollar, but '9', 'G', 'D', 'S'. So we need

* '.' as decimal separator, '-' as minus, '$' as dollar, but not '9', 'G', 'D', 'S'. So we need

cloud-fan · 2022-01-10T13:02:57Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberUtils.scala

+   * 3. 'D' -> '.'
+   * 4. 'S' -> '-'
+   *
+   * Note: When calling format, we must preserve the digits after decimal point, so the digits


I'm not very sure about this behavior, but let's leave the discussion when adding to_char

cloud-fan · 2022-01-10T13:16:03Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberUtils.scala

+   * '.' or 'D': decimal point (only allowed once)
+   * ',' or 'G': group (thousands) separator
+   * '-' or 'S': sign anchored to number
+   * '$': returns value with a leading dollar sign


returns? This is def parse

cloud-fan · 2022-01-10T13:16:38Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberUtils.scala

-    numberDecimalFormat.applyPattern(transformedFormat)
+  private def parse(
+      input: UTF8String,
+      numberFormat: String,


originalNumberFormat?

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberUtils.scala

cloud-fan · 2022-01-10T13:22:35Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberUtils.scala

+    val transformedFormat = transform(normalizedNumberFormat)
+    val numberFormatInstance = NumberFormat.getNumberInstance(Locale.ROOT)
+    assert(numberFormatInstance.isInstanceOf[DecimalFormat])
+    val numberDecimalFormat = numberFormatInstance.asInstanceOf[DecimalFormat]


It's super inefficient to create a NumberFormat instance for every input row.

cloud-fan · 2022-01-10T13:22:54Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberUtils.scala

+
+    val transformedFormat = transform(normalizedNumberFormat)
+    val numberFormatInstance = NumberFormat.getNumberInstance(Locale.ROOT)
+    assert(numberFormatInstance.isInstanceOf[DecimalFormat])


why can't we just do new DecimalFormat()?

cloud-fan · 2022-01-10T13:24:06Z

...talyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/StringExpressionsSuite.scala

+
+    Seq(
+      ("454", "999") -> Decimal(454),
+      ("054", "999") -> Decimal(54),


how about "54" and "999"?

Return Decimal(54). Let's update tests.

cloud-fan · 2022-01-12T08:06:39Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberUtils.scala

+
+    val transformedFormat = transform(normalizedNumberFormat)
+    try {
+      numberDecimalFormat.applyLocalizedPattern(transformedFormat)


do we need to do this for every row?

cloud-fan · 2022-01-12T15:35:27Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberUtils.scala

+    private val transformedFormat = transform(normalizedNumberFormat)
+
+    private lazy val numberDecimalFormat = {
+      val decimalFormat = new DecimalFormat()


can't we do new DecimalFormat(transformedFormat)

cloud-fan · 2022-01-12T15:36:38Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberUtils.scala

+
+    def parse(input: UTF8String): Decimal = {
+      if (unChecked) {
+        check()


I'm confused. This is a static type check, why do you do it at runtime when parsing the first input?

cloud-fan · 2022-01-13T05:24:42Z

...alyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/numberFormatExpressions.scala

+
+  private lazy val numberFormat = right.eval().toString.toUpperCase(Locale.ROOT)
+  private lazy val numberFormatBuilder = new NumberFormatBuilder(numberFormat)
+  private lazy val (precision, scale) = numberFormatBuilder.parsePrecisionAndScale()


nit: it's simpler to have a def parsedDecimalType: DecimalType and use it here.

cloud-fan · 2022-01-17T15:26:34Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberConstants.scala

+    }
+  }
+
+  def parsedDecimalType: DecimalType = DecimalType(precision, scale)


What I expect is

val parsedDecimalType = { val formatSplits = normalizedNumberFormat.split(POINT_SIGN).map(_.filterNot(isSign)) assert(formatSplits.length <= 2) val precision = formatSplits.map(_.length).sum val scale = if (formatSplits.length == 2) formatSplits.last.length else 0 DecimalType(precision, scale) }

precision and scale is used in other place.

cloud-fan · 2022-01-17T15:36:20Z

...talyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/StringExpressionsSuite.scala

+      val format2 = 0.until(input.length).map(_ => '9').mkString
+      val format3 = 0.until(input.length + 1).map(_ => '0').mkString
+      val format4 = 0.until(input.length + 1).map(_ => '9').mkString
+      val format5 = 0.until(input.length + 2).map(_ => '0').mkString


Can we test the mixed case as I proposed before? val format3 = 0.until(input.length + 2).map(i => i % 2).mkString

It's usually not very useful to go deeper into one factor in the test. To test format string that is longer than the value, the + 1 case should be sufficient, we don't need to test + 2. Ditto to the - 2 case.

cloud-fan · 2022-01-17T15:38:26Z

...talyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/StringExpressionsSuite.scala

+    // Test '.' and 'D'
+    checkExceptionInExpression[IllegalArgumentException](
+      ToNumber(Literal("454.2"), Literal("999")),
+      "Format '999' used for parsing string to number or formatting number to string is invalid")


I think we should refine the error message. 999 is indeed a valid number format string. The problem is the input does not match it.

How about

The input string '$input' does not match the given number format: '$format'

cloud-fan · 2022-01-17T15:40:16Z

...talyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/StringExpressionsSuite.scala

+      ToNumber(Literal("454.23"), Literal("00.000")),
+      "Format '00.000' used for parsing string to number or formatting number to string is invalid")
+    checkExceptionInExpression[IllegalArgumentException](
+      ToNumber(Literal("454.23"), Literal("00D000")),


if you really want to test all the cases, please write the test cases only with dot, and run it again after replacing dot with D.

cloud-fan · 2022-01-17T15:41:57Z

...talyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/StringExpressionsSuite.scala

+      ("12,454", "99,999") -> Decimal(12454),
+      ("12,454", "00,000") -> Decimal(12454),
+      ("12,454", "99G999") -> Decimal(12454),
+      ("12,454", "00G000") -> Decimal(12454),


same problem here, please make the tests more readable.

and tests more cases, e.g. different number of digits.

cloud-fan · 2022-01-17T15:43:29Z

sql/core/src/test/resources/sql-tests/inputs/string-functions.sql

+SELECT endswith(null, null);
+
+-- to_number


since we have extensive unit tests, we can only test some common cases in the end-to-end tests

...talyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/StringExpressionsSuite.scala

cloud-fan · 2022-01-19T14:19:33Z

...talyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/StringExpressionsSuite.scala

+      "The input string '123,456' does not match the given number format: '9G9'")
+
+    Seq(
+      ("12,454", "99,999") -> Decimal(12454),


ditto, no need to repeat the test cases manually, we can replace 0 with 9 in the loop body.

cloud-fan · 2022-01-19T14:20:59Z

...talyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/StringExpressionsSuite.scala

+
+    // Test ',' and 'G'
+    checkExceptionInExpression[IllegalArgumentException](
+      ToNumber(Literal("123,456"), Literal("9G9")),


can we also test if the number of , doesn't match? e.g.

to_number('123,456', '999,999,999') to_number('123,456,789', '999,999')

cloud-fan · 2022-01-19T14:21:36Z

...talyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/StringExpressionsSuite.scala

+      ("454-", "000-") -> Decimal(-454),
+      ("454-", "000S") -> Decimal(-454),
+      ("-454", "-000") -> Decimal(-454),
+      ("-454", "S000") -> Decimal(-454),


ditto, replace 9 with 0, - with S in the loop body.

cloud-fan · 2022-01-19T14:22:57Z

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/util/NumberFormatterSuite.scala

 import org.apache.spark.sql.types.Decimal
 import org.apache.spark.unsafe.types.UTF8String

-class NumberUtilsSuite extends SparkFunSuite {
+class NumberFormatterSuite extends SparkFunSuite {


not sure if we still need this test suite since we test almost everything in the new test in StringExpressionsSuite

Just follows StringUtils with StringUtilsSuite. In fact, RegexpExpressionsSuite.scala test almost everything too.

sql/core/src/test/resources/sql-tests/inputs/string-functions.sql

cloud-fan · 2022-01-19T14:24:22Z

sql/core/src/test/resources/sql-tests/inputs/string-functions.sql

+select to_number('454.2', '999.9');
+select to_number('454.2', '000.0');
+select to_number('454.2', '999D9');


ditto for . and D

cloud-fan · 2022-01-19T14:24:28Z

sql/core/src/test/resources/sql-tests/inputs/string-functions.sql

+select to_number('12,454', '99,999');
+select to_number('12,454', '00,000');
+select to_number('12,454', '99G999');


cloud-fan · 2022-01-19T14:24:33Z

sql/core/src/test/resources/sql-tests/inputs/string-functions.sql

+select to_number('$78.12', '$00.00');
+select to_number('-454', '-999');
+select to_number('-454', 'S999');


cloud-fan · 2022-01-20T09:20:39Z

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/util/NumberFormatterSuite.scala

-      input: UTF8String, numberFormat: String, errorMsg: String): Unit = {
-    val e = intercept[IllegalArgumentException](parse(input, numberFormat))
+  private def invalidNumberFormat(numberFormat: String, errorMsg: String): Unit = {
+    val testNumberFormatter = new TestNumberFormatter(numberFormat)


do we really need this TestNumberFormatter? We can simply call check, expect it to return TypeCheckFailure, and check the error message.

cloud-fan

LGTM except for one minor comment, we can address it in the followup PR.

cloud-fan · 2022-01-20T09:22:43Z

thanks, merging to master!

beliefer · 2022-01-20T09:58:22Z

@cloud-fan Thank you for your hard work!

github-actions bot added the SQL label Dec 29, 2021

beliefer mentioned this pull request Dec 30, 2021

[SPARK-34755][SQL] Support the utils for transform number format #31847

Closed

cloud-fan reviewed Dec 30, 2021

View reviewed changes

cloud-fan reviewed Jan 4, 2022

View reviewed changes

github-actions bot added the DOCS label Jan 4, 2022

cloud-fan reviewed Jan 6, 2022

View reviewed changes

docs/sql-ref-number-pattern.md Outdated Show resolved Hide resolved

cloud-fan reviewed Jan 6, 2022

View reviewed changes

cloud-fan reviewed Jan 10, 2022

View reviewed changes

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/NumberUtils.scala Outdated Show resolved Hide resolved

cloud-fan reviewed Jan 10, 2022

View reviewed changes

cloud-fan reviewed Jan 12, 2022

View reviewed changes

cloud-fan reviewed Jan 13, 2022

View reviewed changes

beliefer added 4 commits January 14, 2022 17:14

Update code

ab8df2e

Update code

2d063b4

Update code

d91c73a

Update code

b3906ca

beliefer force-pushed the SPARK-28137-new branch from 59965fc to b3906ca Compare January 14, 2022 09:15

Update code

6f9c379

cloud-fan reviewed Jan 17, 2022

View reviewed changes

beliefer added 2 commits January 18, 2022 15:33

Update code

e81cb72

Update code

a84f450

cloud-fan reviewed Jan 19, 2022

View reviewed changes

...talyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/StringExpressionsSuite.scala Show resolved Hide resolved

cloud-fan reviewed Jan 19, 2022

View reviewed changes

sql/core/src/test/resources/sql-tests/inputs/string-functions.sql Show resolved Hide resolved

cloud-fan reviewed Jan 19, 2022

View reviewed changes

Update code

e6ab6bb

cloud-fan reviewed Jan 20, 2022

View reviewed changes

cloud-fan approved these changes Jan 20, 2022

View reviewed changes

cloud-fan closed this in 9c02dd4 Jan 20, 2022

beliefer mentioned this pull request Jan 21, 2022

[SPARK-28516][SQL] Data Type Formatting Functions: to_char #35269

Closed


		Usage notes for numeric formatting:

		- 0 specifies a digit position that will always be printed, even if it contains a leading/trailing zero. 9 also specifies a digit position, but if it is a leading zero then it will be replaced by a space, while if it is a trailing zero and fill mode is specified then it will be deleted. (For to_number(), these two pattern characters are equivalent.)


		- 0 specifies a digit position that will always be printed, even if it contains a leading/trailing zero. 9 also specifies a digit position, but if it is a leading zero then it will be replaced by a space, while if it is a trailing zero and fill mode is specified then it will be deleted. (For to_number(), these two pattern characters are equivalent.)

		- The pattern characters S, D, and G represent the sign, decimal point, and thousands separator characters. The pattern characters period and comma represent those exact characters, with the meanings of decimal point and thousands separator.

	\|D\|decimal point (only allowed once)\|99D99\|
	\|D\|decimal point, same as . (only allowed once)\|99D99\|

	\|G\|group (thousands) separator\|9G999\|
	\|G\|group (thousands) separator, same as ,\|9G999\|

	* '.' as decimal separator, '-' as minus, '$' as dollar, but '9', 'G', 'D', 'S'. So we need
	* '.' as decimal separator, '-' as minus, '$' as dollar, but not '9', 'G', 'D', 'S'. So we need

[SPARK-28137][SQL] Data Type Formatting Functions: to_number #35060

[SPARK-28137][SQL] Data Type Formatting Functions: to_number #35060

Conversation

beliefer commented Dec 29, 2021 • edited

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

beliefer Dec 31, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cloud-fan Jan 6, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cloud-fan Jan 17, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

beliefer Jan 20, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cloud-fan left a comment

Choose a reason for hiding this comment

cloud-fan commented Jan 20, 2022

beliefer commented Jan 20, 2022

[SPARK-28137][SQL] Data Type Formatting Functions: `to_number` #35060

[SPARK-28137][SQL] Data Type Formatting Functions: `to_number` #35060

beliefer commented Dec 29, 2021 •

edited

beliefer Dec 31, 2021 •

edited

cloud-fan Jan 6, 2022 •

edited

cloud-fan Jan 17, 2022 •

edited

beliefer Jan 20, 2022 •

edited