On 10 October 2017 at 12:44, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > David Rowley <david.rowley@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
