-
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
sql: disallow set-returning functions in CASE expressions #97119
Labels
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
mgartner
added
the
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
label
Feb 14, 2023
DrewKimball
added a commit
to DrewKimball/cockroach
that referenced
this issue
Jun 26, 2023
This patch adds checks during type-checking to ensure that generator functions are not used in the arguments of `CASE` or `COALESCE` expressions. This mirrors postgres behavior. Fixes cockroachdb#97119 Fixes cockroachdb#94890 Release note (bug fix): CASE and COALESCE expressions now return an error when passed a generator function as an argument. This mirrors postgres behavior.
DrewKimball
added a commit
to DrewKimball/cockroach
that referenced
this issue
Jul 14, 2023
This patch adds checks during type-checking to ensure that generator functions are not used in the arguments of `CASE`, `IF`, `COALESCE`, or `IFNULL` expressions. This mirrors postgres behavior. This patch also corrects the error message that is returned in these cases to say "set-returning" instead of "generator". Fixes cockroachdb#97119 Fixes cockroachdb#94890 Release note (bug fix): CASE, IF, COALESCE, and IFNULL expressions now return an error when passed a generator function as an argument. This mirrors postgres behavior.
craig bot
pushed a commit
that referenced
this issue
Jul 18, 2023
105582: opt: check that generator functions are not used in CASE or COALESCE r=DrewKimball a=DrewKimball #### opt: check that generator functions are not used in CASE or COALESCE This patch adds checks during type-checking to ensure that generator functions are not used in the arguments of `CASE`, `IF`, `COALESCE`, or `IFNULL` expressions. This mirrors postgres behavior. This patch also corrects the error message that is returned in these cases to say "set-returning" instead of "generator". Fixes #97119 Fixes #94890 Release note (bug fix): CASE, IF, COALESCE, and IFNULL expressions now return an error when passed a generator function as an argument. This mirrors postgres behavior. 106944: bazel,dev: in `dev`, handle different `--compilation_mode`s correctly... r=rail a=rickystewart ... and switch our default compilation mode to `dbg`. Under `fastbuild`, built binaries are stripped. This is not the case with `dbg`. Have `dev doctor` recommend using `dbg`, and either way make `dev` resilient to whatever kind of `--compilation_mode` you're using. In principle or theory `dbg` is slower than `fastbuild`, but for the Go compiler it generates debuggable binaries by default and you have to opt-in to stripping, so it shoould make no real difference. Now, we think of the `--compilation_mode` simply as follows: `dbg` is the default that everyone is opted into by default unless they explicitly set `-c opt` (we use this for release). For now I don't see a reason anyone would need `fastbuild`. Epic: CRDB-17171 Release note: None Closes: #106820 107086: server: minor improvement around TestTenantInterface r=yuzefovich a=yuzefovich Addresses: #76378. Fixes: #106903. Co-authored-by: Drew Kimball <[email protected]> Co-authored-by: Ricky Stewart <[email protected]> Co-authored-by: Yahor Yuzefovich <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
T-sql-queries
SQL Queries Team
CRDB allows set-returning functions in CASE expressions, while Postgres does not. For example, this succeeds in CRDB but fails in Postgres:
The behavior of such an expression is not well-defined, and the results are unexpected, if not down right incorrect. For example:
I'd expect this expression to return only a single row.
We should probably disallow set-returning functions within CASE expressions (and other conditional expressions).
Jira issue: CRDB-24525
The text was updated successfully, but these errors were encountered: