geo/builtins: st_asgeojson overload with max_decimal_digits does not apply precision #124368
Assignees
Labels
A-sql-builtins
SQL built-in functions and semantics thereof.
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
T-sql-queries
SQL Queries Team
Comments
rharding6373
added
C-bug
|
This bug was most likely introduced by #116570 |
craig bot
pushed a commit
that referenced
this issue
May 21, 2024
123120: ui: Highlight unavailable ranges in red on the summary bar with nonzero r=abarganier a=theloneexplorerquest Modify the summary bar to change the color of unavailable ranges. When the unavailable range is greater than zero, it will be displayed in red; if it is zero, it will be green. Fix: #122014 Release note (ui): Changed the color of unavailable ranges on the summary bar to red when nonzero; ranges are green when zero. 124301: logtestutils: generalize structured logging spy r=xinhaoz a=xinhaoz This commit generalizes the structured logging spy previously being used for datadriven telemetry tests so that it can repurposed for other structured logging channels. Epic: none Release note: None 124403: roachtest: use first transient error when checking for flakes r=srosenberg a=renatolabs Previously, roachtest would only look at the outermost error in a chain that matched a `TransientError` (or `ErrorWithOwnership`) when checking for flakes. However, that is in most cases *not* what we want: if a transient error wraps another transient error, the actual reason for the failure is the original (wrapped) error. Informs: #123887 Release note: None 124425: pkg/server/structlogging: support hot ranges stats with diagnostic reporting disabled r=kyle-a-wong a=kyle-a-wong Previously, enable hot ranges stats also required the enabling of diagnostic reporting. Hot ranges stats doesn't need to be dependent on diagnostic reporting and someone might want to enable hot ranges stats without enabling diagnostic reporting. Now, server.telemetry.hot_ranges_stats.enabled can be set to true while without setting diagnostics.reporting.enabled Epic: none Fixes: #122977 Part of: https://cockroachlabs.atlassian.net/browse/CRDB-38152 Release note: None 124459: builtins: fix st_geojson when max_decimal_digits is specified r=yuzefovich a=yuzefovich This commit fixes a regression in `st_geojson` builtin when `max_decimal_digits` argument is specified which was introduced in 6009141 (during 24.1 cycle). In particular, this overload specifies the precision (rather than using the default number of digits), and that commit made it so that we ignore the precision argument. This is now fixed. Fixes: #124368. Release note (bug fix): CockroachDB previously would ignore `max_decimal_digits` argument of `st_geojson` builtin function and would use the default instead. The bug is only present in 24.1.0 releases. 124491: raft: remove RawNode.TickQuiesced r=pav-kv a=nvanbenschoten This commit removes the `(*RawNode).TickQuiesced` method. The method was deprecated back in etcd-io/raft#62 and has not been in use since 2018. Epic: None Release note: None Co-authored-by: theloneexplorerquest <theloneexplorerquest@gmail.com> Co-authored-by: Xin Hao Zhang <xzhang@cockroachlabs.com> Co-authored-by: Renato Costa <renato@cockroachlabs.com> Co-authored-by: Kyle Wong <kyle.wong@cockroachlabs.com> Co-authored-by: Yahor Yuzefovich <yahor@cockroachlabs.com> Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The st_asgeojson geo builtins has a few overloads with the parameter max_decimal_digits that is supposed to apply a user-provided precision when encoding geo types to json, but this parameter is not applied. Under the hood,
geo.DefaultGeoJSONDecimalDigitis used for precision.Repro:
This appears to be a regression. I can replicate this issue on v24.1.0-alpha.1 but not on v23.2.5.
Jira issue: CRDB-38850
The text was updated successfully, but these errors were encountered: