sql: fix casts between REG* types #75112
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This change is |
otan
approved these changes
Jan 18, 2022
The newly introduced `castMap` does not contain entries for casts between all combinations of REG* types, which is consistent with Postgres, but inconsistent with behavior in versions up to 21.2 where these casts are allowed. The `castMap` changes result in more than just backward incompatibility. We allow branches of CASE statements to be equivalent types (i.e., types in the same family), like `REGCLASS` and `REGTYPE`, and we automatically add casts to a query plan to support this. However, because these casts don't exist in the `castMap`, internal errors are raised when we try to fetch the volatility of the cast while building logical properties. According to Postgres's type conversion rules for CASE, we should only allow branches to be different types if they can be implicitly cast to the first non-NULL branch. Implicit casts between REG* types are not allowed, so CASE expressions with branches of different REG* types should result in a user error like `CASE/WHEN could not convert type regclass to regtype`. However, this is a much larger project and the change will not be fully backward compatible. This work is tracked by issue cockroachdb#75103. For now, this commit adds casts between REG* types to the `castMap` to maintain backward compatibility and prevent an internal error. There is no release note because this bug does not exist in any releases. Fixes cockroachdb#74784 Release note: None
mgartner
force-pushed
the
74784-reg-casts
branch
from
2edcccd to
d09d141
Compare
|
TFTR! bors r+ |
|
Build succeeded: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The newly introduced
castMapdoes not contain entries for castsbetween all combinations of REG* types, which is consistent with
Postgres, but inconsistent with behavior in versions up to 21.2 where
these casts are allowed.
The
castMapchanges result in more than just backward incompatibility.We allow branches of CASE statements to be equivalent types (i.e., types
in the same family), like
REGCLASSandREGTYPE, and we automaticallyadd casts to a query plan to support this. However, because these casts
don't exist in the
castMap, internal errors are raised when we try tofetch the volatility of the cast while building logical properties.
According to Postgres's type conversion rules for CASE, we should only
allow branches to be different types if they can be implicitly cast to
the first non-NULL branch. Implicit casts between REG* types are not
allowed, so CASE expressions with branches of different REG* types
should result in a user error like
CASE/WHEN could not convert type regclass to regtype. However, this is a much larger project and thechange will not be fully backward compatible. This work is tracked by
issue #75103.
For now, this commit adds casts between REG* types to the
castMaptomaintain backward compatibility and prevent an internal error.
There is no release note because this bug does not exist in any
releases.
Fixes #74784
Release note: None