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.eisentraut@xxxxxxxxxxxxxxx> 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
