postgresql/src/test/regress/expected/case.out

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

420 lines
9.0 KiB
Plaintext
Raw Normal View History

2000-01-06 07:40:54 +01:00
--
-- CASE
-- Test the case statement
--
CREATE TABLE CASE_TBL (
1999-02-23 08:30:05 +01:00
i integer,
f double precision
);
2000-01-06 07:40:54 +01:00
CREATE TABLE CASE2_TBL (
1999-02-23 08:30:05 +01:00
i integer,
j integer
);
2000-01-06 07:40:54 +01:00
INSERT INTO CASE_TBL VALUES (1, 10.1);
INSERT INTO CASE_TBL VALUES (2, 20.2);
INSERT INTO CASE_TBL VALUES (3, -30.3);
INSERT INTO CASE_TBL VALUES (4, NULL);
INSERT INTO CASE2_TBL VALUES (1, -1);
INSERT INTO CASE2_TBL VALUES (2, -2);
INSERT INTO CASE2_TBL VALUES (3, -3);
INSERT INTO CASE2_TBL VALUES (2, -4);
INSERT INTO CASE2_TBL VALUES (1, NULL);
INSERT INTO CASE2_TBL VALUES (NULL, -6);
--
-- Simplest examples without tables
--
SELECT '3' AS "One",
1998-12-04 16:36:51 +01:00
CASE
WHEN 1 < 2 THEN 3
1999-02-23 08:30:05 +01:00
END AS "Simple WHEN";
2000-01-06 07:40:54 +01:00
One | Simple WHEN
-----+-------------
3 | 3
1998-12-04 16:36:51 +01:00
(1 row)
2000-01-06 07:40:54 +01:00
SELECT '<NULL>' AS "One",
1998-12-04 16:36:51 +01:00
CASE
WHEN 1 > 2 THEN 3
1999-02-23 08:30:05 +01:00
END AS "Simple default";
2000-01-06 07:40:54 +01:00
One | Simple default
--------+----------------
<NULL> |
1998-12-04 16:36:51 +01:00
(1 row)
2000-01-06 07:40:54 +01:00
SELECT '3' AS "One",
1998-12-04 16:36:51 +01:00
CASE
WHEN 1 < 2 THEN 3
ELSE 4
1999-02-23 08:30:05 +01:00
END AS "Simple ELSE";
2000-01-06 07:40:54 +01:00
One | Simple ELSE
-----+-------------
3 | 3
1998-12-04 16:36:51 +01:00
(1 row)
2000-01-06 07:40:54 +01:00
SELECT '4' AS "One",
1998-12-04 16:36:51 +01:00
CASE
WHEN 1 > 2 THEN 3
ELSE 4
1999-02-23 08:30:05 +01:00
END AS "ELSE default";
2000-01-06 07:40:54 +01:00
One | ELSE default
-----+--------------
4 | 4
1998-12-04 16:36:51 +01:00
(1 row)
2000-01-06 07:40:54 +01:00
SELECT '6' AS "One",
1998-12-04 16:36:51 +01:00
CASE
WHEN 1 > 2 THEN 3
WHEN 4 < 5 THEN 6
ELSE 7
1999-02-23 08:30:05 +01:00
END AS "Two WHEN with default";
2000-01-06 07:40:54 +01:00
One | Two WHEN with default
-----+-----------------------
6 | 6
1998-12-04 16:36:51 +01:00
(1 row)
SELECT '7' AS "None",
CASE WHEN random() < 0 THEN 1
END AS "NULL on no matches";
None | NULL on no matches
------+--------------------
7 |
(1 row)
-- Constant-expression folding shouldn't evaluate unreachable subexpressions
SELECT CASE WHEN 1=0 THEN 1/0 WHEN 1=1 THEN 1 ELSE 2/0 END;
case
------
1
(1 row)
SELECT CASE 1 WHEN 0 THEN 1/0 WHEN 1 THEN 1 ELSE 2/0 END;
case
------
1
(1 row)
-- However we do not currently suppress folding of potentially
-- reachable subexpressions
SELECT CASE WHEN i > 100 THEN 1/0 ELSE 0 END FROM case_tbl;
ERROR: division by zero
-- Test for cases involving untyped literals in test expression
SELECT CASE 'a' WHEN 'a' THEN 1 ELSE 2 END;
case
------
1
(1 row)
2000-01-06 07:40:54 +01:00
--
-- Examples of targets involving tables
--
SELECT
1998-12-04 16:36:51 +01:00
CASE
WHEN i >= 3 THEN i
END AS ">= 3 or Null"
1999-02-23 08:30:05 +01:00
FROM CASE_TBL;
>= 3 or Null
--------------
3
4
1999-02-23 08:30:05 +01:00
(4 rows)
1998-12-04 16:36:51 +01:00
SELECT
CASE WHEN i >= 3 THEN (i + i)
1999-02-23 08:30:05 +01:00
ELSE i
1998-12-04 16:36:51 +01:00
END AS "Simplest Math"
1999-02-23 08:30:05 +01:00
FROM CASE_TBL;
Simplest Math
---------------
1
2
6
8
1999-02-23 08:30:05 +01:00
(4 rows)
SELECT i AS "Value",
1999-02-23 08:30:05 +01:00
CASE WHEN (i < 0) THEN 'small'
WHEN (i = 0) THEN 'zero'
WHEN (i = 1) THEN 'one'
WHEN (i = 2) THEN 'two'
ELSE 'big'
END AS "Category"
FROM CASE_TBL;
Value | Category
-------+----------
1 | one
2 | two
3 | big
4 | big
1999-02-23 08:30:05 +01:00
(4 rows)
1998-12-04 16:36:51 +01:00
SELECT
1999-02-23 08:30:05 +01:00
CASE WHEN ((i < 0) or (i < 0)) THEN 'small'
WHEN ((i = 0) or (i = 0)) THEN 'zero'
WHEN ((i = 1) or (i = 1)) THEN 'one'
WHEN ((i = 2) or (i = 2)) THEN 'two'
1998-12-04 16:36:51 +01:00
ELSE 'big'
END AS "Category"
1999-02-23 08:30:05 +01:00
FROM CASE_TBL;
Category
----------
one
two
big
big
(4 rows)
2000-01-06 07:40:54 +01:00
--
-- Examples of qualifications involving tables
--
--
-- NULLIF() and COALESCE()
-- Shorthand forms for typical CASE constructs
-- defined in the SQL standard.
2000-01-06 07:40:54 +01:00
--
SELECT * FROM CASE_TBL WHERE COALESCE(f,i) = 4;
i | f
---+---
4 |
1999-02-23 08:30:05 +01:00
(1 row)
2000-01-06 07:40:54 +01:00
SELECT * FROM CASE_TBL WHERE NULLIF(f,i) = 2;
i | f
---+---
1999-02-23 08:30:05 +01:00
(0 rows)
2000-01-06 07:40:54 +01:00
SELECT COALESCE(a.f, b.i, b.j)
1999-02-23 08:30:05 +01:00
FROM CASE_TBL a, CASE2_TBL b;
coalesce
----------
10.1
20.2
-30.3
1
10.1
20.2
-30.3
2
10.1
20.2
-30.3
3
10.1
20.2
-30.3
2
10.1
20.2
-30.3
1
10.1
20.2
-30.3
-6
(24 rows)
2000-01-06 07:40:54 +01:00
SELECT *
1999-02-23 08:30:05 +01:00
FROM CASE_TBL a, CASE2_TBL b
WHERE COALESCE(a.f, b.i, b.j) = 2;
2000-01-06 07:40:54 +01:00
i | f | i | j
---+---+---+----
4 | | 2 | -2
4 | | 2 | -4
(2 rows)
SELECT NULLIF(a.i,b.i) AS "NULLIF(a.i,b.i)",
1999-02-23 08:30:05 +01:00
NULLIF(b.i, 4) AS "NULLIF(b.i,4)"
FROM CASE_TBL a, CASE2_TBL b;
NULLIF(a.i,b.i) | NULLIF(b.i,4)
-----------------+---------------
| 1
2 | 1
3 | 1
4 | 1
1 | 2
| 2
3 | 2
4 | 2
1 | 3
2 | 3
| 3
4 | 3
1 | 2
| 2
3 | 2
4 | 2
| 1
2 | 1
3 | 1
4 | 1
1 |
2 |
3 |
4 |
(24 rows)
SELECT *
1999-02-23 08:30:05 +01:00
FROM CASE_TBL a, CASE2_TBL b
WHERE COALESCE(f,b.i) = 2;
i | f | i | j
---+---+---+----
4 | | 2 | -2
4 | | 2 | -4
1999-02-23 08:30:05 +01:00
(2 rows)
-- Tests for constant subexpression simplification
explain (costs off)
SELECT * FROM CASE_TBL WHERE NULLIF(1, 2) = 2;
QUERY PLAN
--------------------------
Result
One-Time Filter: false
(2 rows)
explain (costs off)
SELECT * FROM CASE_TBL WHERE NULLIF(1, 1) IS NOT NULL;
QUERY PLAN
--------------------------
Result
One-Time Filter: false
(2 rows)
explain (costs off)
SELECT * FROM CASE_TBL WHERE NULLIF(1, null) = 2;
QUERY PLAN
--------------------------
Result
One-Time Filter: false
(2 rows)
2000-01-06 07:40:54 +01:00
--
-- Examples of updates involving tables
--
UPDATE CASE_TBL
SET i = CASE WHEN i >= 3 THEN (- i)
1999-02-23 08:30:05 +01:00
ELSE (2 * i) END;
2000-01-06 07:40:54 +01:00
SELECT * FROM CASE_TBL;
i | f
----+-------
2 | 10.1
4 | 20.2
-3 | -30.3
-4 |
1999-02-23 08:30:05 +01:00
(4 rows)
2000-01-06 07:40:54 +01:00
UPDATE CASE_TBL
1999-02-23 08:30:05 +01:00
SET i = CASE WHEN i >= 2 THEN (2 * i)
ELSE (3 * i) END;
2000-01-06 07:40:54 +01:00
SELECT * FROM CASE_TBL;
i | f
-----+-------
4 | 10.1
8 | 20.2
-9 | -30.3
-12 |
1999-02-23 08:30:05 +01:00
(4 rows)
1998-12-04 16:36:51 +01:00
2000-01-06 07:40:54 +01:00
UPDATE CASE_TBL
1999-02-23 08:30:05 +01:00
SET i = CASE WHEN b.i >= 2 THEN (2 * j)
ELSE (3 * j) END
FROM CASE2_TBL b
WHERE j = -CASE_TBL.i;
2000-01-06 07:40:54 +01:00
SELECT * FROM CASE_TBL;
i | f
-----+-------
8 | 20.2
-9 | -30.3
-12 |
-8 | 10.1
(4 rows)
Fix two errors with nested CASE/WHEN constructs. ExecEvalCase() tried to save a cycle or two by passing &econtext->caseValue_isNull as the isNull argument to its sub-evaluation of the CASE value expression. If that subexpression itself contained a CASE, then *isNull was an alias for econtext->caseValue_isNull within the recursive call of ExecEvalCase(), leading to confusion about whether the inner call's caseValue was null or not. In the worst case this could lead to a core dump due to dereferencing a null pointer. Fix by not assigning to the global variable until control comes back from the subexpression. Also, avoid using the passed-in isNull pointer transiently for evaluation of WHEN expressions. (Either one of these changes would have been sufficient to fix the known misbehavior, but it's clear now that each of these choices was in itself dangerous coding practice and best avoided. There do not seem to be any similar hazards elsewhere in execQual.c.) Also, it was possible for inlining of a SQL function that implements the equality operator used for a CASE comparison to result in one CASE expression's CaseTestExpr node being inserted inside another CASE expression. This would certainly result in wrong answers since the improperly nested CaseTestExpr would be caused to return the inner CASE's comparison value not the outer's. If the CASE values were of different data types, a crash might result; moreover such situations could be abused to allow disclosure of portions of server memory. To fix, teach inline_function to check for "bare" CaseTestExpr nodes in the arguments of a function to be inlined, and avoid inlining if there are any. Heikki Linnakangas, Michael Paquier, Tom Lane Report: https://github.com/greenplum-db/gpdb/pull/327 Report: <4DDCEEB8.50602@enterprisedb.com> Security: CVE-2016-5423
2016-08-08 16:33:46 +02:00
--
-- Nested CASE expressions
--
-- This test exercises a bug caused by aliasing econtext->caseValue_isNull
Faster expression evaluation and targetlist projection. This replaces the old, recursive tree-walk based evaluation, with non-recursive, opcode dispatch based, expression evaluation. Projection is now implemented as part of expression evaluation. This both leads to significant performance improvements, and makes future just-in-time compilation of expressions easier. The speed gains primarily come from: - non-recursive implementation reduces stack usage / overhead - simple sub-expressions are implemented with a single jump, without function calls - sharing some state between different sub-expressions - reduced amount of indirect/hard to predict memory accesses by laying out operation metadata sequentially; including the avoidance of nearly all of the previously used linked lists - more code has been moved to expression initialization, avoiding constant re-checks at evaluation time Future just-in-time compilation (JIT) has become easier, as demonstrated by released patches intended to be merged in a later release, for primarily two reasons: Firstly, due to a stricter split between expression initialization and evaluation, less code has to be handled by the JIT. Secondly, due to the non-recursive nature of the generated "instructions", less performance-critical code-paths can easily be shared between interpreted and compiled evaluation. The new framework allows for significant future optimizations. E.g.: - basic infrastructure for to later reduce the per executor-startup overhead of expression evaluation, by caching state in prepared statements. That'd be helpful in OLTPish scenarios where initialization overhead is measurable. - optimizing the generated "code". A number of proposals for potential work has already been made. - optimizing the interpreter. Similarly a number of proposals have been made here too. The move of logic into the expression initialization step leads to some backward-incompatible changes: - Function permission checks are now done during expression initialization, whereas previously they were done during execution. In edge cases this can lead to errors being raised that previously wouldn't have been, e.g. a NULL array being coerced to a different array type previously didn't perform checks. - The set of domain constraints to be checked, is now evaluated once during expression initialization, previously it was re-built every time a domain check was evaluated. For normal queries this doesn't change much, but e.g. for plpgsql functions, which caches ExprStates, the old set could stick around longer. The behavior around might still change. Author: Andres Freund, with significant changes by Tom Lane, changes by Heikki Linnakangas Reviewed-By: Tom Lane, Heikki Linnakangas Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
-- with the isNull argument of the inner CASE's CaseExpr evaluation. After
Fix two errors with nested CASE/WHEN constructs. ExecEvalCase() tried to save a cycle or two by passing &econtext->caseValue_isNull as the isNull argument to its sub-evaluation of the CASE value expression. If that subexpression itself contained a CASE, then *isNull was an alias for econtext->caseValue_isNull within the recursive call of ExecEvalCase(), leading to confusion about whether the inner call's caseValue was null or not. In the worst case this could lead to a core dump due to dereferencing a null pointer. Fix by not assigning to the global variable until control comes back from the subexpression. Also, avoid using the passed-in isNull pointer transiently for evaluation of WHEN expressions. (Either one of these changes would have been sufficient to fix the known misbehavior, but it's clear now that each of these choices was in itself dangerous coding practice and best avoided. There do not seem to be any similar hazards elsewhere in execQual.c.) Also, it was possible for inlining of a SQL function that implements the equality operator used for a CASE comparison to result in one CASE expression's CaseTestExpr node being inserted inside another CASE expression. This would certainly result in wrong answers since the improperly nested CaseTestExpr would be caused to return the inner CASE's comparison value not the outer's. If the CASE values were of different data types, a crash might result; moreover such situations could be abused to allow disclosure of portions of server memory. To fix, teach inline_function to check for "bare" CaseTestExpr nodes in the arguments of a function to be inlined, and avoid inlining if there are any. Heikki Linnakangas, Michael Paquier, Tom Lane Report: https://github.com/greenplum-db/gpdb/pull/327 Report: <4DDCEEB8.50602@enterprisedb.com> Security: CVE-2016-5423
2016-08-08 16:33:46 +02:00
-- evaluating the vol(null) expression in the inner CASE's second WHEN-clause,
-- the isNull flag for the case test value incorrectly became true, causing
-- the third WHEN-clause not to match. The volatile function calls are needed
-- to prevent constant-folding in the planner, which would hide the bug.
-- Wrap this in a single transaction so the transient '=' operator doesn't
-- cause problems in concurrent sessions
BEGIN;
Fix two errors with nested CASE/WHEN constructs. ExecEvalCase() tried to save a cycle or two by passing &econtext->caseValue_isNull as the isNull argument to its sub-evaluation of the CASE value expression. If that subexpression itself contained a CASE, then *isNull was an alias for econtext->caseValue_isNull within the recursive call of ExecEvalCase(), leading to confusion about whether the inner call's caseValue was null or not. In the worst case this could lead to a core dump due to dereferencing a null pointer. Fix by not assigning to the global variable until control comes back from the subexpression. Also, avoid using the passed-in isNull pointer transiently for evaluation of WHEN expressions. (Either one of these changes would have been sufficient to fix the known misbehavior, but it's clear now that each of these choices was in itself dangerous coding practice and best avoided. There do not seem to be any similar hazards elsewhere in execQual.c.) Also, it was possible for inlining of a SQL function that implements the equality operator used for a CASE comparison to result in one CASE expression's CaseTestExpr node being inserted inside another CASE expression. This would certainly result in wrong answers since the improperly nested CaseTestExpr would be caused to return the inner CASE's comparison value not the outer's. If the CASE values were of different data types, a crash might result; moreover such situations could be abused to allow disclosure of portions of server memory. To fix, teach inline_function to check for "bare" CaseTestExpr nodes in the arguments of a function to be inlined, and avoid inlining if there are any. Heikki Linnakangas, Michael Paquier, Tom Lane Report: https://github.com/greenplum-db/gpdb/pull/327 Report: <4DDCEEB8.50602@enterprisedb.com> Security: CVE-2016-5423
2016-08-08 16:33:46 +02:00
CREATE FUNCTION vol(text) returns text as
'begin return $1; end' language plpgsql volatile;
SELECT CASE
(CASE vol('bar')
WHEN 'foo' THEN 'it was foo!'
WHEN vol(null) THEN 'null input'
WHEN 'bar' THEN 'it was bar!' END
)
WHEN 'it was foo!' THEN 'foo recognized'
WHEN 'it was bar!' THEN 'bar recognized'
ELSE 'unrecognized' END;
case
----------------
bar recognized
(1 row)
-- In this case, we can't inline the SQL function without confusing things.
CREATE DOMAIN foodomain AS text;
CREATE FUNCTION volfoo(text) returns foodomain as
'begin return $1::foodomain; end' language plpgsql volatile;
CREATE FUNCTION inline_eq(foodomain, foodomain) returns boolean as
'SELECT CASE $2::text WHEN $1::text THEN true ELSE false END' language sql;
CREATE OPERATOR = (procedure = inline_eq,
leftarg = foodomain, rightarg = foodomain);
SELECT CASE volfoo('bar') WHEN 'foo'::foodomain THEN 'is foo' ELSE 'is not foo' END;
case
------------
is not foo
(1 row)
ROLLBACK;
-- Test multiple evaluation of a CASE arg that is a read/write object (#14472)
-- Wrap this in a single transaction so the transient '=' operator doesn't
-- cause problems in concurrent sessions
BEGIN;
CREATE DOMAIN arrdomain AS int[];
CREATE FUNCTION make_ad(int,int) returns arrdomain as
'declare x arrdomain;
begin
x := array[$1,$2];
return x;
end' language plpgsql volatile;
CREATE FUNCTION ad_eq(arrdomain, arrdomain) returns boolean as
'begin return array_eq($1, $2); end' language plpgsql;
CREATE OPERATOR = (procedure = ad_eq,
leftarg = arrdomain, rightarg = arrdomain);
SELECT CASE make_ad(1,2)
WHEN array[2,4]::arrdomain THEN 'wrong'
WHEN array[2,5]::arrdomain THEN 'still wrong'
WHEN array[1,2]::arrdomain THEN 'right'
END;
case
-------
right
(1 row)
ROLLBACK;
-- Test interaction of CASE with ArrayCoerceExpr (bug #15471)
BEGIN;
CREATE TYPE casetestenum AS ENUM ('e', 'f', 'g');
SELECT
CASE 'foo'::text
WHEN 'foo' THEN ARRAY['a', 'b', 'c', 'd'] || enum_range(NULL::casetestenum)::text[]
ELSE ARRAY['x', 'y']
END;
array
-----------------
{a,b,c,d,e,f,g}
(1 row)
ROLLBACK;
2000-01-06 07:40:54 +01:00
--
-- Clean up
--
DROP TABLE CASE_TBL;
DROP TABLE CASE2_TBL;