Re: SQL - find 'missing' numbers

On Tue, Sep 29, 2015 at 3:12 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 9/29/2015 1:00 PM, John Yeung wrote:

I don't know if what he and Buck described would be considered a
"common SQL idiom" for producing a temporary range of numbers. I mean,
it definitely feels to me as though it might be. My SQL is just too
rudimentary for me to make that judgment.

But it also might be worth including a quick comment in the code that
lets less advanced readers know that "hey, we're just generating a
range of numbers here". Just a thought, for the sake of future
readability and maintainability.

Are you thinking about snippets being posted to the list? Thanks for
the gentle reminder. This particular subject line is applicable enough
to the snippets, but thread drift can really make for an unusual
interpretation of uncommented code if using the... deprecated subject
line. :-)

You're welcome, I think. But to be perfectly honest, I was really
thinking about comments in live, production code. That is, I was
suggesting that if you use a recursive CTE in this manner in your
actual code base, it might be helpful to other people who have to read
the code (possibly including a later version of yourself) to include a
brief note explaining it.

But I was speaking from the perspective of someone who is pretty weak
at SQL. If that RCTE is more-or-less standard for fluent SQL
programmers, then I'm inclined to withdraw the suggestion, or at least
play it down. In fact, I've already started to get more comfortable
with the snippets you and Chuck provided. I'm sure it's very natural
for Lisp programmers, as they've traditionally done all their loops
with recursion anyway.

As someone who programs in a language where your except (from
Birgitta) is expressed as simply

range(10, 250, 10)

the SQL still seems verbose, even if it's becoming more understandable
by the hour. So maybe my suggestion is morphing into a vague idea of
wrapping up the RCTE in a function (UDF? stored procedure? I'm too
much of noob to know the proper terminology here), which would
accomplish both brevity (of the code that calls it) and documentation.

John