Re: [PATCH] Simplify EXISTS subqueries containing LIMIT
От | Marti Raudsepp |
---|---|
Тема | Re: [PATCH] Simplify EXISTS subqueries containing LIMIT |
Дата | |
Msg-id | CABRT9RBR5Bg22naun51pBB5Uj6Ey0RB5bSZe_VniZ4HusTdhag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Simplify EXISTS subqueries containing LIMIT (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: [PATCH] Simplify EXISTS subqueries containing LIMIT
|
Список | pgsql-hackers |
Hi Thanks for taking a look. On Sun, Oct 19, 2014 at 1:22 PM, David Rowley <dgrowleyml@gmail.com> wrote: > the argument for this would > have been much stronger if anti join support had just been added last week. > It's been quite a few years now and the argument for this must be getting > weaker with every release. I see your point, but I would put it another way: we've had this for a few years, but people haven't learned and are *still* using LIMIT 1. ---- Actually I thought of a cleverer approach to solve this, that doesn't require calling eval_const_expressions and works with any expression. Given query: EXISTS (SELECT ... WHERE foo LIMIT any_expr()) we could turn it into the almost-equivalent form: EXISTS (SELECT ... WHERE foo AND any_expr() > 0) The only problem is that we'd no longer be able to throw an error for negative values and that seems like a deal-breaker. Regards, Marti
В списке pgsql-hackers по дате отправления: