[SPARK-48906][SQL] Introduce `SHOW COLLATIONS LIKE ...` syntax to show all collations #47364

panbingkun · 2024-07-16T03:17:46Z

What changes were proposed in this pull request?

The pr aims to introduce SHOW COLLATIONS LIKE ... syntax to show all collations.

Why are the changes needed?

End-users will be able to obtain collations currently supported by the spark through SQL.
Other databases, such as MySQL, also have similar syntax,
ref: https://dev.mysql.com/doc/refman/9.0/en/show-collation.html

postgresql: https://database.guide/how-to-return-a-list-of-available-collations-in-postgresql/

Does this PR introduce any user-facing change?

Yes, end-users will be able to obtain collation currently supported by the spark through commands similar to the following

name	provider	version	binaryEquality	binaryOrdering	lowercaseEquality

spark-sql (default)> SHOW COLLATIONS;
UTF8_BINARY	spark	1.0	true	true	false
UTF8_LCASE	spark	1.0	false	false	true
ff_Adlm	icu	153.120.0.0	false	false	false
ff_Adlm_CI	icu	153.120.0.0	false	false	false
ff_Adlm_AI	icu	153.120.0.0	false	false	false
ff_Adlm_CI_AI	icu	153.120.0.0	false	false	false
...

spark-sql (default)> SHOW COLLATIONS LIKE '*UTF8_BINARY*';
UTF8_BINARY	spark	1.0	true	true	false
Time taken: 0.043 seconds, Fetched 1 row(s)

How was this patch tested?

Add new UT.

Was this patch authored or co-authored using generative AI tooling?

No.

…w all collations

panbingkun · 2024-07-16T03:21:12Z

cc @cloud-fan @mihailom-db

panbingkun · 2024-07-17T02:27:11Z

Currently only show normalized collation name.

panbingkun · 2024-07-17T02:44:20Z

If necessary, we can also show columns: CaseSensitivity and AccentSensitivity

panbingkun · 2024-07-17T03:10:45Z

Another option:

when execute SHOW COLLATIONS ..., only show columns: name, provider and version
when execute DESCRIBE COLLATIONS ..., will display columns: name, provider, version, binary_equality, binary_ordering, lowercase_equality, case_sensitivity and accent_sensitivity.

mihailom-db · 2024-07-22T07:33:46Z

Hi @panbingkun, thanks for taking initiative to push this work forward. The design of the table was discussed previously and the structure that was agreed upon should take a slightly different format.
Let me list out things we need to include:

COLLATION_CATALOG (important for udf collations, for now it should be SYSTEM)
COLLATION_SCHEMA (important for udf collations, for now it should be BUILTIN)
COLLATION_NAME (Full name, with all identifiers, just like you did) ✅
LANGUAGE (Name of the language that corresponds to the locale of given collation. Null if there is no backing language (e.g. for UTF8_* family of collations))
COUNTRY (Name of the country that corresponds to the locale of given collation. Null if there is no backing country (e.g. for UTF8_* family of collations))
ACCENT_SENSITIVITY (ACCENT_SENSITIVE/ACCENT_INSENSITIVE)
CASE_SENSITIVITY (CASE_SENSITIVE/CASE_INSENSITIVE)
PAD_ATTRIBUTE (Attribute affects whether leading or trailing spaces are significant in string comparisons. Currently always NO_PAD)
ICU_VERSION (Null if not icu collation) (✅, partially done, just switch UTF8_* family to null)

All fields should be of string type and only language, country and version should be nullable.

Apart from SQL API, we need to support other APIs as well, which should be used by calling Session.catalog.collation. Because of this, your approach might need to be reworked a bit.

Please let me know if you have any additional questions and we can work through this PR together.

mihailom-db · 2024-07-22T07:39:24Z

common/unsafe/src/main/java/org/apache/spark/sql/catalyst/util/CollationFactory.java

@@ -91,7 +91,7 @@ public Optional<String> getVersion() {
  /**
   * Entry encapsulating all information about a collation.
   */
-  public static class Collation {
+  public static class Collation implements Comparable<Collation> {


Is this really needed? When do we want to order them? I would say list/table building should be deterministic and should always output collations in the same way. Also I would expect UTF8_* family collations to come in first as they represent OSS internal implementations.

mihailom-db · 2024-07-22T07:49:34Z

docs/sql-ref-ansi-compliance.md

@@ -442,6 +442,7 @@ Below is a list of all the keywords in Spark SQL.
 |CODEGEN|non-reserved|non-reserved|non-reserved|
 |COLLATE|reserved|non-reserved|reserved|
 |COLLATION|reserved|non-reserved|reserved|
+|COLLATIONS|reserved|non-reserved|reserved|


When we look at MySQL, they use SHOW COLLATION, PostgreSQL uses pg_collation catalog, so I would argue use of COLLATION keyword is sufficient, so let's keep this keyword free.

Okay,

The reason for using COLLATIONS is that I want to follow some of Spark's unwritten rules, eg:

spark/sql/api/src/main/antlr4/org/apache/spark/sql/catalyst/parser/SqlBaseParser.g4

Line 223 in 42d1479

| SHOW TABLES ((FROM | IN) identifierReference)?

spark/sql/api/src/main/antlr4/org/apache/spark/sql/catalyst/parser/SqlBaseParser.g4

Line 227 in 42d1479

| SHOW TBLPROPERTIES table=identifierReference

spark/sql/api/src/main/antlr4/org/apache/spark/sql/catalyst/parser/SqlBaseParser.g4

Line 229 in 42d1479

| SHOW COLUMNS (FROM | IN) table=identifierReference

Of course, if we decide to use COLLATION, I am fine too.

Will follow-up on this a bit later, let's leave it as COLLATIONS for now, and then we can just revert keyword addition if we decide to switch to COLLATION.

mihailom-db · 2024-07-22T07:52:01Z

sql/core/src/test/scala/org/apache/spark/sql/CollationSuite.scala

+    checkAnswer(sql("SHOW COLLATIONS LIKE '*UTF8_BINARY*'"),
+      Row("UTF8_BINARY", "spark", "1.0", true, true, false))
+    checkAnswer(sql("SHOW COLLATIONS '*zh_Hant_HKG*'"),
+      Seq(Row("zh_Hant_HKG", "icu", "153.120.0.0", false, false, false),


This version seems weird, I would say it should contain 75.1 as the version of ICU library. @nikolamand-db do you have any more info on is this expected?

mihailom-db · 2024-07-22T08:07:08Z

common/unsafe/src/main/java/org/apache/spark/sql/catalyst/util/CollationFactory.java

@@ -918,4 +967,8 @@ public static String getClosestSuggestionsOnInvalidName(

    return String.join(", ", suggestions);
  }
+
+  public static List<Collation> fetchAllCollations() {


This operation seems a bit too expensive. We always build the whole table and then do a like on it. We need to do something similar to show tables where we have the pattern, as we do not want to ask for collation information if like operator is not concerned with it. Also it feels pretty weird to have fetchAllCollations in many places like this. This is not as expensive as building the whole table, but we are also allocating ArrayList multiple times

Let me try to think of a better way.

panbingkun · 2024-07-22T08:08:09Z

Apart from SQL API, we need to support other APIs as well, which should be used by calling Session.catalog.collation. Because of this, your approach might need to be reworked a bit.

@mihailom-db
Thank you very much for your reply (very detailed). Okay, let's work together to complete it.
I only have a small question, do we only use one command to display all the fields in the above list,

1.`SHOW COLLATIONS LIKE ....`

COLLATION_CATALOG	COLLATION_SCHEMA	COLLATION_NAME	LANGUAGE	COUNTRY	ACCENT_SENSITIVITY	CASE_SENSITIVITY	PAD_ATTRIBUTE	ICU_VERSION
SYSTEM	BUILTIN	UTF8_BINARY	NULL	NULL	ACCENT_SENSITIVE	CASE_SENSITIVITY	NO_PAD	NULL
SYSTEM	BUILTIN	UTF8_LCASE	NULL	NULL	ACCENT_SENSITIVE	CASE_INSENSITIVE	NO_PAD	NULL
...	...	...	...	...	...	...	...	...

2.or do we use two commands, eg:

A.SHOW COLLATIONS LIKE ....

COLLATION_NAME
UTF8_BINARY
UTF8_LCASE
...

B.DESCRIBE COLLATION UTF8_BINARY

COLLATION_CATALOG	COLLATION_SCHEMA	COLLATION_NAME	LANGUAGE	COUNTRY	ACCENT_SENSITIVITY	CASE_SENSITIVITY	PAD_ATTRIBUTE	ICU_VERSION
SYSTEM	BUILTIN	UTF8_BINARY	NULL	NULL	ACCENT_SENSITIVE	CASE_SENSITIVITY	NO_PAD	NULL

Which of the above is more suitable?

mihailom-db · 2024-07-22T08:10:56Z

I believe for now we agreed to have only SHOW COLLATION(S) as a command, and then add support for both LIKE and ILIKE operators for searching. But it is enough to have LIKE as a start, and ILIKE can be done as an addition later.

panbingkun · 2024-07-22T08:12:42Z

I believe for now we agreed to have only SHOW COLLATION(S) as a command, and then add support for both LIKE and ILIKE operators for searching. But it is enough to have LIKE as a start, and ILIKE can be done as an addition later.

Okay.

…/spark into show_collation_syntax

panbingkun · 2024-07-23T03:07:52Z

@mihailom-db All suggestions have been updated and verified locally as follows:

mihailom-db · 2024-07-23T06:43:58Z

Hi @panbingkun this is starting to look like what we want to get as a result. Thanks for taking the initiative. Apart from the SQL command for SHOW COLLATIONS we need to get the other APIs working. Usually how we list tables and databases for other APIs is through use of catalog information. This is the point where we need to make sure we make the initial design properly. I would argue catalog and schema information should not be stored per collation, but actually only inferred for the purpose of listing here. This becomes crucially important later when we introduce user-defined collations, as these collations will not be available in the list of ICU locales. I will take one more look into how this could be done completely and will get back to you.

panbingkun · 2024-07-23T07:29:04Z

Hi @panbingkun this is starting to look like what we want to get as a result. Thanks for taking the initiative. Apart from the SQL command for SHOW COLLATIONS we need to get the other APIs working. Usually how we list tables and databases for other APIs is through use of catalog information. This is the point where we need to make sure we make the initial design properly. I would argue catalog and schema information should not be stored per collation, but actually only inferred for the purpose of listing here. This becomes crucially important later when we introduce user-defined collations, as these collations will not be available in the list of ICU locales. I will take one more look into how this could be done completely and will get back to you.

@mihailom-db
Thank you very much for your detailed explanation and response!
Looking forward to your take one more look into results!

mihailom-db · 2024-08-01T06:31:19Z

common/unsafe/src/main/java/org/apache/spark/sql/catalyst/util/CollationFactory.java

+          COLLATION_SCHEMA,
+          collationName(),
+          ICULocaleMap.get(locale).getLanguage(),
+          ICULocaleMap.get(locale).getCountry(),


Could we possible change here to getDisplayCountry() and getDisplayLanguage(). The idea is to later be able to look for locales not only on name, but also on country name i.e. Greece, France...

mihailom-db · 2024-08-01T06:53:57Z

common/unsafe/src/main/java/org/apache/spark/sql/catalyst/util/CollationFactory.java

@@ -734,6 +865,10 @@ public CollationIdentifier identifier() {
  public static final String PROVIDER_ICU = "icu";
  public static final List<String> SUPPORTED_PROVIDERS = List.of(PROVIDER_SPARK, PROVIDER_ICU);

+  private static final String COLLATION_CATALOG = "SYSTEM";
+  private static final String COLLATION_SCHEMA = "BUILTIN";


I do not think this information should be stored here, could you take a look at ShowTablesCommand. What we do there is get the catalog and then work on from there. We could actually do something similar here, as UDF collations in future will be defined with catalog and schema fields, and will be stored somewhere. This is a future problem, but for now, let's try to keep code as close as what we will need in future.

Ideally we would love to have a buffer on session.catalog level called collations and then store any user defined collations in there.

Okay, let me think about it again.

mihailom-db · 2024-08-01T06:58:42Z

Hi @panbingkun I left some comments for you, sorry for the delay. I believe you are really close to getting to the point of what we want from SHOW COLLATIONS command and if you happen to have any questions feel free to ping me. Thanks again for taking this innitiative.

panbingkun · 2024-08-01T08:09:02Z

Hi @panbingkun I left some comments for you, sorry for the delay. I believe you are really close to getting to the point of what we want from SHOW COLLATIONS command and if you happen to have any questions feel free to ping me. Thanks again for taking this innitiative.

Thank you very much for your patient review, let me update based on your suggestions.
(Also, this PR is not currently the longest time span PR I have been working on. I remember there was another PR that spanned 1 year and 3 months, joking, 😄)

mihailom-db · 2024-09-11T04:43:46Z

@cloud-fan @MaxGekk could you take a look at this PR?

uros-db

lgtm

MaxGekk

@panbingkun Could you resolve conflicts, please.

panbingkun · 2024-09-11T13:30:22Z

@panbingkun Could you resolve conflicts, please.

Done, thanks!

MaxGekk

@panbingkun It seems the test failure is related to your changes:

[info] - SPARK-43119: Get SQL Keywords *** FAILED *** (11 milliseconds)
[info]   "...LLATE,COLLATION,COLL[ATIONS,COLLECTION],COLUMN,COLUMNS,COMM..." did not equal "...LLATE,COLLATION,COLL[ECTION,COLLECTIONS],COLUMN,COLUMNS,COMM..." (ThriftServerWithSparkContextSuite.scala:217)
[info]   Analysis:
[info]   "...LLATE,COLLATION,COLL[ATIONS,COLLECTION],COLUMN,COLUMNS,COMM..." -> "...LLATE,COLLATION,COLL[ECTION,COLLECTIONS],COLUMN,COLUMNS,COMM..."

Could you fix it, please.

panbingkun · 2024-09-11T22:00:59Z

@panbingkun It seems the test failure is related to your changes:

[info] - SPARK-43119: Get SQL Keywords *** FAILED *** (11 milliseconds)
[info]   "...LLATE,COLLATION,COLL[ATIONS,COLLECTION],COLUMN,COLUMNS,COMM..." did not equal "...LLATE,COLLATION,COLL[ECTION,COLLECTIONS],COLUMN,COLUMNS,COMM..." (ThriftServerWithSparkContextSuite.scala:217)
[info]   Analysis:
[info]   "...LLATE,COLLATION,COLL[ATIONS,COLLECTION],COLUMN,COLUMNS,COMM..." -> "...LLATE,COLLATION,COLL[ECTION,COLLECTIONS],COLUMN,COLUMNS,COMM..."

Could you fix it, please.

Sorry, it was bad. I made a hasty correction, but this time it should have been correct.
Let's wait for GA, thank you very much!

MaxGekk · 2024-09-12T00:10:57Z

+1, LGTM. Merging to master.
Thank you, @panbingkun and @mihailom-db @uros-db for review.

panbingkun · 2024-09-12T00:49:43Z

+1, LGTM. Merging to master. Thank you, @panbingkun and @mihailom-db @uros-db for review.

Thanks all @MaxGekk @mihailom-db @uros-db ❤️

cloud-fan · 2024-09-12T03:15:22Z

Hi all, sorry for the late review as I've been struggling with the user-facing API. I know we have a lot SHOW commands already but there are known issues:

It's not standard, but we don't have a choice as Spark doesn't have information schema yet.
The SHOW ... LIKE ... semantic is different from the LIKE operator. It's also different from Hive's behavior which we copied from.
No corresponding DataFrame API.
We can't perform transformations with the output, something like SELECT ... FROM (SHOW ...) is not allowed.

Building information schema is a big effort, but for this SHOW COLLATIONS feature, can we add a builtin TVF like SELECT ... FROM all_collations()? Also cc @srielau

cloud-fan · 2024-09-12T03:16:57Z

BTW we already have a TVF to get all the SQL keywords

@ExpressionDescription(
  usage = """_FUNC_() - Get Spark SQL keywords""",
  examples = """
    Examples:
      > SELECT * FROM _FUNC_() LIMIT 2;
       ADD  false
       AFTER  false
  """,
  since = "3.5.0",
  group = "generator_funcs")
case class SQLKeywords() extends LeafExpression with Generator with CodegenFallback {
  override def elementSchema: StructType = new StructType()
    .add("keyword", StringType, nullable = false)
    .add("reserved", BooleanType, nullable = false)

  override def eval(input: InternalRow): IterableOnce[InternalRow] = {
    val reservedList = getReservedList()
    keywords.zip(reservedList).map { case (keyword, isReserved) =>
      InternalRow(UTF8String.fromString(keyword), isReserved)
    }
  }

  override def prettyName: String = "sql_keywords"
}

panbingkun · 2024-09-12T10:47:12Z

Hi all, sorry for the late review as I've been struggling with the user-facing API. I know we have a lot SHOW commands already but there are known issues:

It's not standard, but we don't have a choice as Spark doesn't have information schema yet.

The SHOW ... LIKE ... semantic is different from the LIKE operator. It's also different from Hive's behavior which we copied from.

No corresponding DataFrame API.

We can't perform transformations with the output, something like SELECT ... FROM (SHOW ...) is not allowed.

Building information schema is a big effort, but for this SHOW COLLATIONS feature, can we add a builtin TVF like SELECT ... FROM all_collations()? Also cc @srielau

Okay, let's investigate carefully first.

panbingkun · 2024-09-12T10:57:25Z

I think it's possible, let me try it out.

panbingkun · 2024-09-12T11:47:30Z

about TVF all_collations: #48087

MaxGekk · 2024-09-12T11:53:59Z

I think the command could be useful in the migration from other systems that have already such command:

cloud-fan · 2024-09-12T14:11:43Z

It might not be useful if our SHOW ... LIKE ... semantic is different from all other systems...

…LLATIONS` command ### What changes were proposed in this pull request? The pr aims to - introduce `TVF` `collations()`. - remove the `SHOW COLLATIONS` command. ### Why are the changes needed? Based on cloud-fan's suggestion: #47364 (comment) I believe that after this, we can do many things based on it, such as `filtering` and `querying` based on `LANGUAGE` or `COUNTRY`, etc. eg: ```sql SELECT * FROM collations() WHERE LANGUAGE like '%Chinese%'; ``` ### Does this PR introduce _any_ user-facing change? Yes, provide a new TVF `collations()` for end-users. ### How was this patch tested? - Add new UT. - Pass GA. ### Was this patch authored or co-authored using generative AI tooling? No. Closes #48087 from panbingkun/SPARK-49611. Lead-authored-by: panbingkun <panbingkun@baidu.com> Co-authored-by: panbingkun <pbk1982@gmail.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com>

…w all collations ### What changes were proposed in this pull request? The pr aims to introduce `SHOW COLLATIONS LIKE ...` syntax to `show all collations`. ### Why are the changes needed? End-users will be able to obtain `collations` currently supported by the spark through SQL. Other databases, such as `MySQL`, also have similar syntax, ref: https://dev.mysql.com/doc/refman/9.0/en/show-collation.html <img width="958" alt="image" src="https://github.com/user-attachments/assets/1d5106b3-f8b8-42c5-b3ad-0f35c61ad5e2"> postgresql: https://database.guide/how-to-return-a-list-of-available-collations-in-postgresql/ ### Does this PR introduce _any_ user-facing change? Yes, end-users will be able to obtain `collation` currently supported by the spark through commands similar to the following |name|provider|version|binaryEquality|binaryOrdering|lowercaseEquality| | --------- | ----------- | ----------- | ----------- | ----------- | ----------- | ``` spark-sql (default)> SHOW COLLATIONS; UTF8_BINARY spark 1.0 true true false UTF8_LCASE spark 1.0 false false true ff_Adlm icu 153.120.0.0 false false false ff_Adlm_CI icu 153.120.0.0 false false false ff_Adlm_AI icu 153.120.0.0 false false false ff_Adlm_CI_AI icu 153.120.0.0 false false false ... spark-sql (default)> SHOW COLLATIONS LIKE '*UTF8_BINARY*'; UTF8_BINARY spark 1.0 true true false Time taken: 0.043 seconds, Fetched 1 row(s) ``` <img width="513" alt="image" src="https://github.com/user-attachments/assets/d5765e32-718d-4236-857d-d508f5473329"> ### How was this patch tested? Add new UT. ### Was this patch authored or co-authored using generative AI tooling? No. Closes apache#47364 from panbingkun/show_collation_syntax. Authored-by: panbingkun <panbingkun@baidu.com> Signed-off-by: Max Gekk <max.gekk@gmail.com>

…LLATIONS` command ### What changes were proposed in this pull request? The pr aims to - introduce `TVF` `collations()`. - remove the `SHOW COLLATIONS` command. ### Why are the changes needed? Based on cloud-fan's suggestion: apache#47364 (comment) I believe that after this, we can do many things based on it, such as `filtering` and `querying` based on `LANGUAGE` or `COUNTRY`, etc. eg: ```sql SELECT * FROM collations() WHERE LANGUAGE like '%Chinese%'; ``` ### Does this PR introduce _any_ user-facing change? Yes, provide a new TVF `collations()` for end-users. ### How was this patch tested? - Add new UT. - Pass GA. ### Was this patch authored or co-authored using generative AI tooling? No. Closes apache#48087 from panbingkun/SPARK-49611. Lead-authored-by: panbingkun <panbingkun@baidu.com> Co-authored-by: panbingkun <pbk1982@gmail.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com>

…w all collations ### What changes were proposed in this pull request? The pr aims to introduce `SHOW COLLATIONS LIKE ...` syntax to `show all collations`. ### Why are the changes needed? End-users will be able to obtain `collations` currently supported by the spark through SQL. Other databases, such as `MySQL`, also have similar syntax, ref: https://dev.mysql.com/doc/refman/9.0/en/show-collation.html <img width="958" alt="image" src="https://github.com/user-attachments/assets/1d5106b3-f8b8-42c5-b3ad-0f35c61ad5e2"> postgresql: https://database.guide/how-to-return-a-list-of-available-collations-in-postgresql/ ### Does this PR introduce _any_ user-facing change? Yes, end-users will be able to obtain `collation` currently supported by the spark through commands similar to the following |name|provider|version|binaryEquality|binaryOrdering|lowercaseEquality| | --------- | ----------- | ----------- | ----------- | ----------- | ----------- | ``` spark-sql (default)> SHOW COLLATIONS; UTF8_BINARY spark 1.0 true true false UTF8_LCASE spark 1.0 false false true ff_Adlm icu 153.120.0.0 false false false ff_Adlm_CI icu 153.120.0.0 false false false ff_Adlm_AI icu 153.120.0.0 false false false ff_Adlm_CI_AI icu 153.120.0.0 false false false ... spark-sql (default)> SHOW COLLATIONS LIKE '*UTF8_BINARY*'; UTF8_BINARY spark 1.0 true true false Time taken: 0.043 seconds, Fetched 1 row(s) ``` <img width="513" alt="image" src="https://github.com/user-attachments/assets/d5765e32-718d-4236-857d-d508f5473329"> ### How was this patch tested? Add new UT. ### Was this patch authored or co-authored using generative AI tooling? No. Closes apache#47364 from panbingkun/show_collation_syntax. Authored-by: panbingkun <panbingkun@baidu.com> Signed-off-by: Max Gekk <max.gekk@gmail.com>

…LLATIONS` command ### What changes were proposed in this pull request? The pr aims to - introduce `TVF` `collations()`. - remove the `SHOW COLLATIONS` command. ### Why are the changes needed? Based on cloud-fan's suggestion: apache#47364 (comment) I believe that after this, we can do many things based on it, such as `filtering` and `querying` based on `LANGUAGE` or `COUNTRY`, etc. eg: ```sql SELECT * FROM collations() WHERE LANGUAGE like '%Chinese%'; ``` ### Does this PR introduce _any_ user-facing change? Yes, provide a new TVF `collations()` for end-users. ### How was this patch tested? - Add new UT. - Pass GA. ### Was this patch authored or co-authored using generative AI tooling? No. Closes apache#48087 from panbingkun/SPARK-49611. Lead-authored-by: panbingkun <panbingkun@baidu.com> Co-authored-by: panbingkun <pbk1982@gmail.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com>

[SPARK-48906][SQL] Introduce SHOW COLLATIONS LIKE ... syntax to sho…

1fde4b4

…w all collations

github-actions bot added the SQL label Jul 16, 2024

panbingkun marked this pull request as ready for review July 16, 2024 03:21

fix UT

bc5ce3a

github-actions bot added the DOCS label Jul 16, 2024

panbingkun added 2 commits July 16, 2024 16:48

Merge branch 'master' into show_collation_syntax

7c76601

fix ut

395e40a

[MINOR][SQL] Fix CollationFactorySuite

4dfb5e0

mihailom-db reviewed Jul 22, 2024

View reviewed changes

panbingkun added 5 commits July 22, 2024 16:22

Merge branch 'master' into show_collation_syntax

a8ed3e3

Merge branch 'master' into show_collation_syntax

e30b5a6

update

0411f6d

Merge branch 'show_collation_syntax' of https://github.com/panbingkun…

5928f59

…/spark into show_collation_syntax

update

15cf451

panbingkun requested a review from mihailom-db July 23, 2024 03:08

mihailom-db reviewed Aug 1, 2024

View reviewed changes

Merge branch 'master' into show_collation_syntax

d7a7d81

update

261f3c3

uros-db approved these changes Sep 11, 2024

View reviewed changes

MaxGekk reviewed Sep 11, 2024

View reviewed changes

panbingkun added 2 commits September 11, 2024 21:27

fix conflict

949e16a

fix conflict

dbeeb62

MaxGekk approved these changes Sep 11, 2024

View reviewed changes

MaxGekk reviewed Sep 11, 2024

View reviewed changes

panbingkun added 2 commits September 12, 2024 05:54

Merge branch 'master' into show_collation_syntax

811196e

update

dd966fa

MaxGekk closed this in 0f4d289 Sep 12, 2024

panbingkun mentioned this pull request Sep 12, 2024

[SPARK-49611][SQL] Introduce TVF collations() & remove the SHOW COLLATIONS command #48087

Closed

stevomitric mentioned this pull request Oct 28, 2024

[SPARK-50032][SQL] Allow use of fully qualified collation name #48546

Closed

[SPARK-48906][SQL] Introduce SHOW COLLATIONS LIKE ... syntax to show all collations #47364

[SPARK-48906][SQL] Introduce SHOW COLLATIONS LIKE ... syntax to show all collations #47364

Conversation

panbingkun commented Jul 16, 2024 • edited Loading

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?

Was this patch authored or co-authored using generative AI tooling?

panbingkun commented Jul 16, 2024 • edited Loading

panbingkun commented Jul 17, 2024

panbingkun commented Jul 17, 2024

panbingkun commented Jul 17, 2024 • edited Loading

mihailom-db commented Jul 22, 2024 • edited Loading

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

panbingkun commented Jul 22, 2024

1.SHOW COLLATIONS LIKE ....

2.or do we use two commands, eg:

mihailom-db commented Jul 22, 2024

panbingkun commented Jul 22, 2024

panbingkun commented Jul 23, 2024

mihailom-db commented Jul 23, 2024

panbingkun commented Jul 23, 2024

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

mihailom-db commented Aug 1, 2024

panbingkun commented Aug 1, 2024

mihailom-db commented Sep 11, 2024

uros-db left a comment

Choose a reason for hiding this comment

MaxGekk left a comment

Choose a reason for hiding this comment

panbingkun commented Sep 11, 2024

MaxGekk left a comment

Choose a reason for hiding this comment

panbingkun commented Sep 11, 2024

MaxGekk commented Sep 12, 2024

panbingkun commented Sep 12, 2024

cloud-fan commented Sep 12, 2024

cloud-fan commented Sep 12, 2024

panbingkun commented Sep 12, 2024

panbingkun commented Sep 12, 2024

panbingkun commented Sep 12, 2024

MaxGekk commented Sep 12, 2024 • edited Loading

cloud-fan commented Sep 12, 2024

[SPARK-48906][SQL] Introduce `SHOW COLLATIONS LIKE ...` syntax to show all collations #47364

[SPARK-48906][SQL] Introduce `SHOW COLLATIONS LIKE ...` syntax to show all collations #47364

panbingkun commented Jul 16, 2024 •

edited

Loading

panbingkun commented Jul 16, 2024 •

edited

Loading

panbingkun commented Jul 17, 2024 •

edited

Loading

mihailom-db commented Jul 22, 2024 •

edited

Loading

1.`SHOW COLLATIONS LIKE ....`

MaxGekk commented Sep 12, 2024 •

edited

Loading