Re: pgsql: Make decompilation of optimized CASE constructs more robust. - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Make decompilation of optimized CASE constructs more robust.
Date
Msg-id 10387.1307384741@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Make decompilation of optimized CASE constructs more robust.  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-committers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 27.05.2011 02:44, Tom Lane wrote:
>> Make decompilation of optimized CASE constructs more robust.

> I'm afraid this is still wrong. The "=" OpExpr might also get replaced
> with another OpExpr as part of inlining.

Yeah, but looking at operator names is not going to be sufficient to
prove whether that has happened.  The new OpExpr could also use an
operator that's named "=".

Even if we did check for this, the output would *still* be ambiguous and
hence confusing to anybody who didn't understand what was going on,
because it's not obvious that the literally-printed WHEN expression
is going to be used as a boolean rather than compared to the CASE's test
expression.

In the end, I think that decompilation of post-planner query structures
is something we can only do on a "best effort" basis; it's never going
to be perfect, because sometimes we produce things that simply don't
directly match any standard SQL construct.  As long as it produces the
right answer for constructs as they appear in views, I'm not going to
get overly excited about it.

            regards, tom lane

pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Reset reindex-in-progress state before reverifying an exclusion
Next
From: Tom Lane
Date:
Subject: pgsql: Fix rewriter to cope (more or less) with CTEs in the query being