Re: pgsql: Make decompilation of optimized CASE constructs more robust.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Make decompilation of optimized CASE constructs more robust.
Date: 2011-06-06 18:25:41
Message-ID: 10387.1307384741@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2011-06-07 04:09:11 pgsql: Fix rewriter to cope (more or less) with CTEs in the query being
Previous Message Tom Lane 2011-06-06 02:31:36 pgsql: Reset reindex-in-progress state before reverifying an exclusion