[SERVER-25954] Support more granular collation specification Created: 02/Sep/16  Updated: 26/Dec/23

Status: Backlog
Project: Core Server
Component/s: Querying
Affects Version/s: 3.4.0
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Jeffrey Yemin Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: read-only-views
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-84198 Facilitate multiple collations within... Closed
is duplicated by SERVER-49046 Provide the ability to perform a coll... Closed
Related
related to SERVER-53637 Allow collation to be specified for a... Closed
is related to SERVER-55653 Queries on time-series views do not a... Closed
Assigned Teams:
Query Execution
Participants:
Case:

 Description   

Additional use cases for collation would be enabled if it could be specified at a more granular level than per-operation. Some examples:

  • A compound index or sort criteria with different collations for each key
  • A query filter with different collations per operator
  • An aggregation pipeline with different collations per stage (e.g. a case-insensitive collation for a $match and a case-sensitive one for a subsequent $sort)
  • A read-only view with different collations for the view itself, a view that it depends on, and an operation on the view (this would be enabled by allowing a collation per aggregation stage)


 Comments   
Comment by David Percy [ 11/Jun/21 ]

A read-only view with different collations for the view itself, a view that it depends on, and an operation on the view (this would be enabled by allowing a collation per aggregation stage)

The last bullet seems to enable some security leaks.

Just to clarify, I think this ticket is proposing a way to avoid introducing those security leaks. We definitely don't want a view definition to change its meaning based on how you query it. If we could attach a collation to each stage separately, then a query specifying collation A, running on a view defined with collation B, could all run correctly (each stage using the appropriate collation).

Comment by Asya Kamsky [ 13/Sep/16 ]

All of these except the last bullet are reasonable requests.

The last bullet seems to enable some security leaks.

Generated at Thu Feb 08 04:10:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.