*Adrian*: > > If order is not an issue in the production code why test for it in the > test code?
In many cases, it would not be a problem in tests if we had an unordered array comparison helper. But in other cases, it is a production issue. In ruby ActiveRecord for exemple, you can do `Patient.find_by(last_name: 'champier')`, which translates to `SELECT "patients".* FROM "patients" WHERE "patients"."last_name" = 'champier' LIMIT 1`. If last_name is not unique, the returned record will be random. So yes, everything as to be randomized, because the sources are multiples and the consequences can vary to a dramatic production bug, a failed CI 1% of the time, or to a useless test assertion. *Peter*: > It might be an interesting exercise to implement this as a post-parsing > hook. I known nothing about that, but that sounds interesting, do you have any documentation pointer to help me implement that? On Wed, Jul 24, 2019 at 10:36 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-07-23 17:43, Cyril Champier wrote: > > In this documentation > > <https://www.postgresql.org/docs/9.1/queries-order.html>, it is said: > > > > If sorting is not chosen, the rows will be returned in an > > unspecified order. The actual order in that case will depend on the > > scan and join plan types and the order on disk, but it must not be > > relied on. > > > > > > I would like to know if there is any way to change that to have a "real" > > random behaviour. > > It might be an interesting exercise to implement this as a post-parsing > hook. > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
