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. asked 14 Oct '10, 13:00 Volker Barth Mark Culp |
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. answered 14 Oct '10, 14:16 Breck Carter |
You could wrap the complex expression into a derived table. A quick little example with the demo database:
Edit: This could also be made into a function of its own...
Resulting in a fairly friendly syntax:
And depending on when you expect this list to change, you could make the function deterministic, so the result may end up being cached. answered 14 Oct '10, 16:09 Tyson Lewis 1
Thanks, yes, that's a workaround I could use (and a common table expression would be another alternative, I guess). But in my current situation, the SELECT LIST()... itself is used as a subquery-expression in the SELECT list of a complex query, and that seems to make it too complex to work (for my brain, at least). - So a simple LIST(col1 ORDER BY 1) would be wayyyy easier:) 1
@Volker I tried to help make a shorthand in the edit above, perhaps that'll help. Sorry no documentation, just something I drafted up. |
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.