-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
release-21.1: assorted pgwire and sql shell backports #66130
Conversation
Similar to cockroachdb#57265, this commit matches the PG behavior to only show the minutes offset if it is non-zero. Release note (bug fix): Minute timezone offsets are only displayed in the wire protocol if they are non-zero for TimestampTZ and TimeTZ values. Previously, they would always display. Release note (bug fix): Binary TimeTZ values were not being decoded correctly when being sent as a parameter in the wire protocol. This is now fixed.
Release note (cli change): The SQL shell now formats times with time zones so that the minutes and seconds offsets are only shown if they are non-zero. Also, infinite floating point values are formatted as `Infinity` rather than `Inf` now.
Release note (bug fix): CockroachDB's SQL shell now properly displays results of common array types, for example arrays of floats or arrays of strings.
b93cbb5
to
aba5a3d
Compare
i'll let @otan weigh in since he was opposed to the tz offset change being backported (#65341 (review)) -- but we can revisit this discussion |
Yeah I think it's too big a change for a minor version (if we think it fits, why not every version before as well?). |
@@ -1134,6 +1145,11 @@ func formatVal( | |||
if colType == "FLOAT4" { | |||
width = 32 | |||
} | |||
if math.IsInf(t, 1) { | |||
return "Infinity" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my concern is anyone relying on this right now on a major version who wants a quick patch to some other problem but this breaks something else unexpectedly.
I'd be in favor of backporting to every (supported) version before as well -- that's just v21.1 and v20.2. to me it doesn't seem that risky, since we are conforming closer to the pg spec/implementation, and we already know that all tools expect this new adjusted format. is the concern that people may have implemented custom CRDB drivers that don't work with Postgres at all? |
would love an opinion on the above |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, i guess the likelihood of someone having a really bad time with this is very slim.
since the rebase is effort too, and we're backporting it all the way down, i'm content with this being backported.
ok cool, I'll send the backport PR for 20.2 too then. Cheers |
Backport:
Please see individual PRs for details.
/cc @cockroachdb/release