Re: Bug Report: Error caused due to wrong ordering of filters

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Ekta Khanna <ekhanna(at)pivotal(dot)io>
Cc: pgsql-hackers(at)postgresql(dot)org, Sambitesh Dash <sdash(at)pivotal(dot)io>
Subject: Re: Bug Report: Error caused due to wrong ordering of filters
Date: 2018-05-08 11:23:13
Message-ID: 87in7y75zy.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Ekta" == Ekta Khanna <ekhanna(at)pivotal(dot)io> writes:

Ekta> Hello PGSQL Hackers,

Ekta> We have come across the following issue on Postgres
Ekta> REL_10_STABLE. Below is the repro:
[...]
Ekta> In the plan, we see that planner merges the quals from FROM
Ekta> clause and the WHERE clause in the same RESTRICTINFO. Is this the
Ekta> expected behavior?

Yes, it's entirely expected. You CANNOT make assumptions about the order
of evaluation of quals; the planner will rearrange them freely, even
across subquery boundaries (where the semantics allow).

You can do this:

WHERE CASE WHEN length(b) = 8
THEN to_date(b, 'YYYYMMDD') > '2018-05-04'
ELSE false END

since one of the few guarantees about execution order is that a CASE
will evaluate its condition tests before any non-constant subexpressions
in the corresponding THEN clause.

(Another method is to put an OFFSET 0 in the subquery, but that's more
of a hack)

--
Andrew (irc:RhodiumToad)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2018-05-08 11:33:48 Re: Built-in connection pooling
Previous Message Justin Pryzby 2018-05-08 11:05:42 Re: doc fixes: vacuum_cleanup_index_scale_factor