When using the wonderful LIST aggregate with a rather complex expression, how can I specify the order within the list? I want to have the list ordered by the complex expression itself but would not want to repeat the whole term. Something like
would be sufficient, but unfortunately, order-by ordinal (here: 1) is not allowed for list. Neither is it allowed to give the complex expression an alias and use that as order-by expression. As to the docs, I seem to be allowed to use an integral variable ("order by MyInt") but as I'm using a view, that possibility seems to fail, too. Repeating the whole expression does work, but I would like to avoid that. Any hints for a "shorter syntax" are highly appreciated:) - I'm using SA 11.0.1.2427. EDIT: If no such possibility exists, I would suggest to add that in future version - cf. Breck's answer. |
I vote "yes" for an "ORDER BY SELF" enhancement, or ORDER BY 1, or simply ORDERED. The examples in the Help, such as SELECT LIST( EmployeeID ORDER BY Surname ), simply do not exist in the real world... I cannot imagine ever needing to see '1013,191,750,921,868,1658,...' Yes, I know what the Help is trying to show, and yes, I often use ORDER BY other-columns-not-in-the-list-expression, but in the simple cases ORDER BY SELF is what is needed: SELECT LIST( EmployeeID ORDER BY EmployeeID ) http://dcx.sybase.com/index.html#1200en/dbreference/list-function.html The Help DOES seem to imply that SELECT LIST( Street ) FROM Employees without an ORDER BY is implicitly ordered by Street: '487 Kennedy Court, 547 School Street' which is in fact just an accident. |
Good one... until now I was happy with LIST(), I didn't know I wanted that, now I am all disappointed and dissatisfied :)
...but I'm sure you would want a DBMS without LIST() even less, right?
Indeed... LIST ranks up there with DEFAULT TIMESTAMP as features the other vendors just don't get let alone have.
If I remember correctly, in version 7.0 there was no ORDER BY for LIST and a clever customer used DISTINCT for this purpose, recognizing that in 7.0 DISTINCT aggregates were only ever computed by sorting the input to the group-by node by the (single) DISTINCT aggregate's argument. Sadly this "neat trick" no longer works because the hash group-by method can now evaluate multiple distinct aggregates and it doesn't enforce an ordering on the argument. Some execution plans may order, others may not.