Skip to content
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

Closed
mgartner opened this issue Feb 14, 2023 · 0 comments · Fixed by #105582
Closed

sql: disallow set-returning functions in CASE expressions #97119

mgartner opened this issue Feb 14, 2023 · 0 comments · Fixed by #105582
Assignees
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
Projects

Comments

@mgartner
Copy link
Collaborator

mgartner commented Feb 14, 2023

CRDB allows set-returning functions in CASE expressions, while Postgres does not. For example, this succeeds in CRDB but fails in Postgres:

SELECT CASE WHEN true THEN generate_series(1, 3) ELSE 1 END;

The behavior of such an expression is not well-defined, and the results are unexpected, if not down right incorrect. For example:

defaultdb> SELECT CASE WHEN false THEN generate_series(1, 3) ELSE 1 END;
  case
--------
     1
     1
     1
(3 rows)

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

@mgartner 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
@mgartner mgartner added this to Triage in SQL Queries via automation Feb 14, 2023
@blathers-crl blathers-crl bot added the T-sql-queries SQL Queries Team label Feb 14, 2023
@rytaft rytaft moved this from Triage to Active in SQL Queries Feb 21, 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 <drewk@cockroachlabs.com>
Co-authored-by: Ricky Stewart <ricky@cockroachlabs.com>
Co-authored-by: Yahor Yuzefovich <yahor@cockroachlabs.com>
@craig craig bot closed this as completed in 5cc456b Jul 18, 2023
SQL Queries automation moved this from Active to Done Jul 18, 2023
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
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants