Code analysis rule 6702 does not fit for pipelined functions

Hi all,

code analysis rule 6702 grumbles when pipelined functions don't have a RETURN statement. Pipelined functions never have a RETURN statement, so the rule doesn't fit for them.

Best regards

Good catch, thank you! Will be fixed. (QP-4075)

FYI, I have a colleague who says that it's still best practice to have an "empty" RETURN in PFs, but you're right, it's not required and Code Analysis should accommodate... thank you Quest Dev!

1 Like

Gary you say something! Steven Feuerstein in also uses empty RETURNs.
I guess the reason is that RETURN inside a function has become part of many developer's DNA. :slight_smile:

But Rainer may have meant that the RETURN here is not mandatory and that is true, so the rule should not grumble.

1 Like

Agreed... not mandatory/required, so our Code Analysis shouldn't "grumble" at valid syntax ... :slight_smile:

The fix is fairly simple. If you want to test it yourself then create a rule in user space (#7000-9999) with the following expression:

  (::: Find non-pipelined functions which don't have at least one RETURN statement :::)
    $f[not(.//RETURN/ancestor::FUNCTION_BODY[1][@offset = $f/@offset])]   (::: RETURN must not belong to
                                                                             a nested function body :::)
       (::: Mark the last "END" in the function :::)
       /STMT/BLOCK/TOKEN[@value = "end"][last()]

Otherwise expect it in Toad beta in a few weeks.

You guys at Quest are so quick and cool... :+1:t3:

I don't plan to create a user defined rule, but I look forward to the fix in one of the next releases (usually I don't use betas). The fix has no hurry.

In fact I did not know that one can use an empty RETURN statement in pipelined functions and I apologize to Steven Feuerstein that I did not read his blog post :wink: but I own his Oracle PL/SQL Programming book instead :slight_smile:

Greetings from Germany and a nice weekend to all of you