Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan - Mailing list pgsql-performance

From Claudio Freire
Subject Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan
Date
Msg-id CAGTBQpZ6D8YSyM8V5KFmKZyM5F_psPe8hA5hNDDx-nMOdK9jmQ@mail.gmail.com
Whole thread Raw
In response to Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-performance
On Thu, May 2, 2013 at 9:48 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> SELECT count(k0.id)
>>> FROM k0
>>> WHERE 1 = 2
>>>     OR k0.id IN (
>>>         SELECT k1.k0_id
>>>         FROM k1
>>>         WHERE k1.k1k2_id IN (
>>>                 SELECT k2.k1k2_id
>>>                 FROM k2
>>>                 WHERE k2.t = 2
>>>                     AND (coalesce(k2.z, '')) LIKE '%12%'
>>>                 )
>>>         );
>>
...
>
> The situation shown could be the result of SQL injection attack.
>
> It would be nice to have a switch to do additional checks on SQL
> queries to ensure such injections don't cause long runtimes to return
> useless answers.

How could that be the case without becoming much much worse than large runtimes?

I don't think it's the place of the database to worry about SQL injection.


pgsql-performance by date:

Previous
From: Simon Riggs
Date:
Subject: Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan
Next
From: mark.kirkwood@catalyst.net.nz
Date:
Subject: Re: In progress INSERT wrecks plans on table