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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Make decompilation of optimized CASE constructs more robust.
Дата
Msg-id 10387.1307384741@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: Make decompilation of optimized CASE constructs more robust.  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: pgsql: Reset reindex-in-progress state before reverifying an exclusion
Следующее
От: Tom Lane
Дата:
Сообщение: pgsql: Fix rewriter to cope (more or less) with CTEs in the query being