On Mon, Apr 10, 2017 at 1:35 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > "David G. Johnston" <david.g.johnston@xxxxxxxxx> writes: >> On Mon, Apr 10, 2017 at 11:02 AM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: >>> Sure, but isn't it fair to consider that an implementation artifact? > >> So, the presence of ORDER BY in the aggregate function call is a PostgreSQL >> extension... > >> It seems reasonable to declare that the order of the values in the >> generated array match whatever order the FROM clause supplies the rows. If >> that is not acceptable a PostgreSQL-specific ORDER BY modifier can be added >> which will cause an additional sort-and-scan of the input relation to occur >> (optimized across multiple column invocations when possible). > > Yes, and in fact we documented the ORDER-BY-in-subselect solution back > before we had the ORDER-BY-in-aggregate feature. I don't remember exactly > where, but I'm sure it's still described somewhere. So it is documented > behavior that an aggregate without its own ORDER BY will see the rows in > whatever order the FROM clause supplies them. The documentation is a bit ambiguous on the topic TBH. Via https://www.postgresql.org/docs/9.6/static/functions-aggregate.html: "The aggregate functions array_agg, json_agg, jsonb_agg, json_object_agg, jsonb_object_agg, string_agg, and xmlagg, as well as similar user-defined aggregate functions, produce meaningfully different result values depending on the order of the input values. This ordering is unspecified by default, but can be controlled by writing an ORDER BY clause within the aggregate call, as shown in Section 4.2.7. Alternatively, supplying the input values from a sorted subquery will usually work. For example: SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab; Beware that this approach can fail if the outer query level contains additional processing, such as a join, because that might cause the subquery's output to be reordered before the aggregate is computed." If you think the behavior ought to be defined to work that way, that's fine by me. A small documentation fix could clarify that, I think. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
