diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2011-05-26 19:25:19 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2011-05-26 19:25:36 -0400 |
| commit | 0bd7305ffb16b238dea79d5f98f88c745fe21db8 (patch) | |
| tree | 12c675fa2a2cbd8e955143689896c16940fa25a6 /src/backend/commands | |
| parent | c2a366d9d9d3b1e2dc4c65d9a9fab5c1c0d6c246 (diff) | |
Make decompilation of optimized CASE constructs more robust.
We had some hacks in ruleutils.c to cope with various odd transformations
that the optimizer could do on a CASE foo WHEN "CaseTestExpr = RHS" clause.
However, the fundamental impossibility of covering all cases was exposed
by Heikki, who pointed out that the "=" operator could get replaced by an
inlined SQL function, which could contain nearly anything at all. So give
up on the hacks and just print the expression as-is if we fail to recognize
it as "CaseTestExpr = RHS". (We must cover that case so that decompiled
rules print correctly; but we are not under any obligation to make EXPLAIN
output be 100% valid SQL in all cases, and already could not do so in some
other cases.) This approach requires that we have some printable
representation of the CaseTestExpr node type; I used "CASE_TEST_EXPR".
Back-patch to all supported branches, since the problem case fails in all.
Diffstat (limited to 'src/backend/commands')
0 files changed, 0 insertions, 0 deletions
