| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, dmitry potapov <potapov(dot)dmitry(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan |
| Date: | 2013-05-02 15:00:28 |
| Message-ID: | CAGTBQpZ6D8YSyM8V5KFmKZyM5F_psPe8hA5hNDDx-nMOdK9jmQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, May 2, 2013 at 9:48 AM, Simon Riggs <simon(at)2ndquadrant(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gavin Flower | 2013-05-02 21:06:03 | Re: In progress INSERT wrecks plans on table |
| Previous Message | Simon Riggs | 2013-05-02 12:48:34 | Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan |