Come to think of it though, I’m not sure that advocates of some of these dysfunctional methods (row-by-row processing vs. set-based, explicit cursors vs. implicit cursors) even believe that what they are doing is more simple than set-based code. It’s almost like a mentality that, “the harder we work on writing the code, the faster it will run”, or to look at it the other way, “if it’s more simple and convenient, it must ipso facto be slower”. The “golden rule” is that you have to work hard for performance, and it’s simply not true.

To go back to the original example of generating lists of dates, what irks me about the exotic methods is that they may outperform a selection from a table in a simple query, but for more complex queries the cardinality estimation issues are promoters of performance problems. More complex, more prone to bugs, more version dependent, more performance issues — use with extreme caution.

(apologies for late reply by the way - forgot I’d posted)

Cheers.

Carlos.

So I bet someone at Oracle has been thinking about this at least since the draft 1992 ANSI SQL standard started circulating.

SQL standards. There’s a job I could not do.

Would I use it in production? Not a chance.