sql: implement IFERROR and ISERROR

[knz]

Fixes #9760.

The SQL scalar operators IFERROR and ISERROR are inspired from the
MSSQL feature of the same name. In their simple form:

• ISERROR(Expr) returns false if Expr evaluates
  without error; true otherwise.
• IFERROR(Expr, Val) returns the value of Expr if Expr evaluates
  without error, otherwise it evaluates and returns Val.

In order to avoid catching too many errors, they exist also in an
"advanced" mode:

• ISERROR(Expr, Code) returns false if Expr evaluates without
  error; otherwise, it evaluates Code, and if Code evaluates
  without error it checks whether the error produced for Expr has pg
  error code that matches Code. If Code is NULL or the pg error
  code matches, ISERROR returns true, otherwise ISERROR returns
  Expr's evaluation error. For example, `ISERROR(1/x, '22012')
  returns true iff Expr evaluates with a "divide by zero" error.

• IFERROR(Expr, Val, Code) evaluates Expr and returns its value if
  no error. If there is an error, it evaluates Code and checks the
  Expr eval error with Code as for ISERROR above. If the error
  code matches, it evaluates and returns Val.

Note: this only covers the evaluation of scalar expressions that
do not require access to data in the underlying KV store.

• If ISERROR/IFERROR is applied to a subquery and the subquery errors
  out, the entire query fails and ISERROR/IFERROR are ineffective.
• In general if the scalar expression causes a KV operation and the KV
  operation fails (e.g. nextval() on a sequence), again the entire
  query fails.
• Some very specific uses of KV may be caught (e.g. ::REGCLASS casts)
  but this is neither tested nor guaranteed.

Release note (sql change): the two experimental scalar operators
IFERROR() and ISERROR() have been introduced. They may be
documented for public use in the future.

[cockroach-teamcity]

This change is 

[knz]

cc @andreimatei

[knz]

Note: I made a mistake in the definition of iserror -- my explanation about "either/or code" is wrong.

[knz]

Fixed, PTAL

[nvanbenschoten]

Reviewed 9 of 9 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

---

pkg/sql/sem/tree/expr.go, line 542 at r1 (raw file):

}

// IfErrExpr represents an IFERR expression.

s/IFERR/IFERROR/

---

pkg/sql/sem/tree/expr.go, line 546 at r1 (raw file):

	Cond    Expr
	Else    Expr
	ErrCond Expr

I would rename ErrCond to ErrCode everywhere. It's a little confusing having multiple "condition" expressions within the same parent Expr.

---

pkg/sql/sem/tree/expr.go, line 579 at r1 (raw file):

}

// IsErrExpr represents an IFERR expression.

s/IFERR/ISERROR/

---

pkg/sql/sem/tree/expr.go, line 580 at r1 (raw file):

// IsErrExpr represents an IFERR expression.
type IsErrExpr struct {

Do you think it's worth folding this into IfErrExpr with a nil Else expression? Should be pretty easy to make that work.

---

pkg/sql/sem/tree/type_check.go, line 621 at r1 (raw file):

	var typedErrCond TypedExpr
	if expr.ErrCond != nil {
		typedErrCond, err = typeCheckAndRequire(ctx, expr.ErrCond, types.String, "IFERROR")

s/IFERROR/ISERROR/

---

Comments from Reviewable

[knz]

Review status: all files reviewed at latest revision, 5 unresolved discussions, some commit checks failed.

---

pkg/sql/sem/tree/expr.go, line 542 at r1 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

s/IFERR/IFERROR/

Done.

---

pkg/sql/sem/tree/expr.go, line 546 at r1 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

I would rename ErrCond to ErrCode everywhere. It's a little confusing having multiple "condition" expressions within the same parent Expr.

Done.

---

pkg/sql/sem/tree/expr.go, line 579 at r1 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

s/IFERR/ISERROR/

Done.

---

pkg/sql/sem/tree/expr.go, line 580 at r1 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

Do you think it's worth folding this into IfErrExpr with a nil Else expression? Should be pretty easy to make that work.

do you mean that iferror(a) should type as boolean whereas iferror(a,b) should type as the type of a and b? That looks fishy. I think we've been pretty disciplined at having 1 expr type === 1 typing rule.

---

pkg/sql/sem/tree/type_check.go, line 621 at r1 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

s/IFERROR/ISERROR/

Done.

---

Comments from Reviewable

[nvanbenschoten]

Review status: 4 of 9 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

---

pkg/sql/sem/tree/expr.go, line 580 at r1 (raw file):

Previously, knz (kena) wrote…

do you mean that iferror(a) should type as boolean whereas iferror(a,b) should type as the type of a and b? That looks fishy. I think we've been pretty disciplined at having 1 expr type === 1 typing rule.

No sorry, I just meant folding these two expression types into a single AST node.

---

Comments from Reviewable

[knz]

Review status: 4 of 9 files reviewed at latest revision, 1 unresolved discussion.

---

pkg/sql/sem/tree/expr.go, line 580 at r1 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

No sorry, I just meant folding these two expression types into a single AST node.

Done. RFAL

---

Comments from Reviewable

[nvanbenschoten]

---

Reviewed 6 of 6 files at r2.
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

---

Comments from Reviewable

[knz]

Thanks!

bors r+

[craig]

Build succeeded

• GitHub CI (Cockroach)