tag:blogger.com,1999:blog-8677649049588007585.post529554460206347889..comments2023-06-18T16:15:22.432+01:00Comments on PL/SQL Challenge: Penalizing players for bugs or undocumented behavior? (2906)Steven Feuersteinhttp://www.blogger.com/profile/16619706770920320550noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-8677649049588007585.post-3900062659613942412011-06-20T15:20:58.619+01:002011-06-20T15:20:58.619+01:00A player who cannot post to the blog sent this:
=...A player who cannot post to the blog sent this:<br /><br />===============================================<br />For what it's worth I wanted to comment on this contentious issue - regarding accepting as correct an answer that contradicts the documentation (in this case, acceptance of OUT and IN OUT parameters by cursor declarations).<br /><br />The PL/SQL challenge has always been about education. A developer who is aware of the nuances and edge cases (such as bugs in the compiler) is that much better equipped for his job, so in this sense a quiz that tests one's knowledge of these bugs is helpful. This point has been made several times in the past for similar types of question.<br /><br />Also, if the test for an "unfair question" is merely that a player would always have to actually type it into a SQL*Plus session and execute it, then by that standard the quiz is not unfair - because I'd be surprised if there weren't at least some players who already knew about this behaviour of the compiler and answered accordingly.<br /><br />For everyone else, their getting this quiz wrong is an opportunity for them to learn something new about PL/SQL - the prospect of which is what keeps me coming back every day.<br />===============================================<br /><br />I intend to continue to offer quizzes and choices in quizzes that both reflect the documented behaviors of the language and its reality.<br /><br />Cheers, SFSteven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-39768831974141191722011-06-18T06:56:12.287+01:002011-06-18T06:56:12.287+01:00Choice 6938 for the June 15, 2011 quiz (2906) shou...Choice 6938 for the June 15, 2011 quiz (2906) should be considered incorrect. Both the text and syntax diagram in <i>Oracle Database PL/SQL Language Reference 11g Release 2 (11.2)</i> unambiguously state that cursor parameters must have a direction of <i>IN</i>. (The same is true of the 10gR2 documentation.) The fact that all versions of the PL/SQL compiler from 10gR2 to 11gR2 accept <i>IN OUT</i> and <i>OUT</i> direction declarations for cursor parameters does not make such use valid PL/SQL. The ability to use these declarations is an attribute of the specific compilers, not of the PL/SQL language.<br /><br />The use of <i>IN OUT</i> looked suspiciously like a trap, so I tried some test code to ascertain its behavior. As a result of my test I selected that choice. Experience with the Challenge has shown that behavior is given more importance than the validity of the PL/SQL code. In some cases, such as when a compiler or runtime defect prevents valid PL/SQL code from performing as expected, this bias may be justified. Quizzes that exploit a compiler’s lax adherence to language specifications in order to achieve a result despite non-compliant PL/SQL code, however, reduce the Challenge to a typing or guessing contest. The choice that prompted this blog post is based on a compiler deficiency that a competent PL/SQL programmer is unlikely to ever encounter; in addition to violating the language specification, the use of <i>IN OUT</i> cursor parameters serves no logical purpose. Such <i>tricks</i> may be interesting, but they have no place in legitimate PL/SQL programming. <br /><br />Behavior contrary to specifications may change in future versions (this is more likely to occur for cases where valid PL/SQL is rejected than it is for cases where invalid PL/SQL is accepted). Most quizzes state a minimum instead of a specific version, thus any choice deemed correct should be expected to remain valid even with future versions.<br /><br />Steven, your book correctly describes Oracle’s specified behavior (the <i>bug</i> is with Oracle’s implementation, not your book). The only change I would make would be to add a footnote such as “The PL/SQL compiler incorrectly accepts <i>IN OUT</i> and <i>OUT</i> cursor parameters. These direction declarations are contrary to the language specification and must not be used."jhall62https://www.blogger.com/profile/10339038131928463003noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-51499176930661128052011-06-17T22:19:49.321+01:002011-06-17T22:19:49.321+01:00What I need to change in my book is the use of the...What I need to change in my book is the use of the "cannot" in: "You cannot specify OUT or IN OUT modes for cursor parameters". <br /><br />You can, in turns out, specify OUT or IN OUT modes. It's just that you should NOT.Steven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-24193655963453116522011-06-17T18:29:25.180+01:002011-06-17T18:29:25.180+01:00Hello Steven, All,
Wim just took the words out of...Hello Steven, All,<br /><br />Wim just took the words out of my mind !!!<br /><br />I also strongly advise AGAINST changing the text in your book. <br /><br />What is written there is completely correct and, let's not forget, people are reading books for learning things right and learning best practices, so there is no place for such a change.<br /><br />The version differences that Wim mentioned above are indeed an issue sometimes, just recently enough we had a quiz about the 11g RESULT_CACHE in which code that compiled in R1 <br />does not compile in R2, which means that the compiler itself is NOT perfect, and, hopefully,<br />it is improving from one version to the next.<br /><br />We all know that there exist behaviors that are undocumented (or at least not in the main Oracle Documentation, but maybe only in White Papers on very specific topics), but also not denied by any documentation part.<br />About these we can argue whether they can be <br />used in the challenge, at which extension, in what flavor, a.s.o.<br /><br />But the specific issue of using cursor parameters as always IN mode only is an already fully clarified one, I think already from the very first version of PL/SQL and I don't see any reason that this behavior will change in the future.<br />The fact that the compiler allows it through without a compilation error is simply a compiler flaw, that I am pretty sure Oracle PL/SQL product developers are not aware of ... they are humans after all, like all of us, but I strongly believe they should be warned about such a basic issue that might cause misunderstandings ...<br /><br />So, just as Wim recommended, your book should maybe add as an introductory sentence, on the first pages, something like:<br /><br />"While practicing PL/SQL, you may and will probably encounter strange behaviors, code that will compile successfully when you expect the opposite or code that compiles correctly but runs unexpectedly or does not run at all.<br />In such cases, it is worth either to stick to the documented behavior or eventually file a compiler bug or even a documentation bug<br />using Oracle's Customer Service for having that issue checked and resolved."<br /><br />Thanks & Best Regards,<br />Iudithiudithhttps://www.blogger.com/profile/04905902445036068357noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-37706365415857861472011-06-17T07:13:03.041+01:002011-06-17T07:13:03.041+01:00What!!!???
"So, yes, you are "penalized&...What!!!???<br />"So, yes, you are "penalized" if you simply checked the documentation and answered according to it, rather than actually trying it out before you submitted your answer."<br />So if you know the documentation by heart (I don't) and you are not taking the time to type all the code over (and check forever for typo's that are intentionly in the quiz or not) you are penalized because the software does not follow the specifications and documentation? Sorry, that is a stupid argument.<br />You don't have to rescore, but the challenge is not about typing the code and testing it? Is it? There are too many versions which could differ in behaviour (even version Oracle Database 10g Release 2 is not specific enough if you know about subversioning that could lead to problems, we had)to state that only the valid answers are the code that is run. The answers with the OUT and IN OUT are clearly in error. If you correct your book (don't) clearly say that the OUT could in certain implementations not lead to compile errors, but that it is clearly wrong, makes no sense, not supported and in future versions could lead to problems.Wim de Langehttps://www.blogger.com/profile/05505341375827859005noreply@blogger.com