• David Walker-278941 (9/23/2009)


    john.arnott (9/23/2009)


    David Walker-278941 (9/23/2009)


    Tao Klerks (9/23/2009)


    David Walker-278941 (9/23/2009)


    Yes, but I'm not forgiving of superfluous apostrophes in the word "its". The sentence gets a Fail. "It's" means "it is" and nothing else.

    Ah but if you're going to be all finicky about it, "it's" can actually mean "it is" or "it has"...

    You're right about that, and I missed it. It's been so long since I used "it's" to mean anything other than "it is" that I forgot about that. 🙂

    Hmmmm. I hadn't noticed that error the other day when the QOD was published. I didn't retain a copy of the original text submitted a couple of months ago, so now I'm curious as to whether its extraneous apostophe is my error or it's something that was introduced by SSC in the editing process. I hope that last sentence demonstrates that I do understand the difference between "it's" and "its".

    Meanwhile, was the parsing exercise valuable to you? Did you learn something?

    To be honest, I didn't learn much that was useful. If there are no blanks between values and their aliases, that's pretty bad coding. And unfortunately for me, when I read bad grammar, it interrupts the flow and breaks my concentration. But that's something I have to work on.

    I would rather start a campaign against unnecessary table aliases, especially in Join statements, than spend time on edge cases in the parser like this. Is it written in the SQL specification that blanks are not required between a value and a column alias, or is it just something that someone observed in one release and in one implementation? If it's not part of the spec, then learning it is not very useful.

    For table alises, programmers seem to get the idea that they are a required part of the syntax. In fact, for many readers, having to read someone else's code with Join statements that are full of table aliases requires an extra level of concentration. Table aliases are *sometimes* required, but not all of the time. They hinder human readability. Trying to unlearn bad behavior (unneccessary table aliases) is more important than worrying about oddball syntax parsing. 🙂

    I agree with David regarding unnecessary table aliases.

    Just on it, that we should alias a table when a table has been used multiple times in a single SQL (considering sub-query also).