Re: [GENERAL] Equivalence Classes when using IN
От | David Rowley |
---|---|
Тема | Re: [GENERAL] Equivalence Classes when using IN |
Дата | |
Msg-id | CAKJS1f96SVOb64cF2=w5cCL9zY2k5+WwRxUVOgfazCZ=Z=M1BA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] Equivalence Classes when using IN (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On 10 October 2017 at 12:44, Tom Lane <tgl@sss.pgh.pa.us> wrote: > David Rowley <david.rowley@2ndquadrant.com> writes: >> If the only reason that is_simple_subquery() rejects subqueries with >> ORDER BY is due to wanting to keep the order by of a view, then >> couldn't we make is_simple_subquery() a bit smarter and have it check >> if the subquery is going to be joined to something else, which likely >> would destroy the order, or at least it would remove any guarantees of >> it. > > I'm not on board with this. The assumption is that if the user put an > ORDER BY there, that means they want that subquery to be computed in that > order. It's not for us to decide they didn't mean what they said. > > Moreover, there are cases where the ORDER BY would be semantically > significant, eg if there's a LIMIT or volatile functions or tSRFs > involved. Ok, thanks for looking, although, FWIW, LIMIT and tSRFs are still disabled. -- David Rowley http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
В списке pgsql-general по дате отправления: