@Pazus, did you manage to get any progress on that issue?

How are things going with fixing the error? :-)

@Pazus, do you think it will be feasible to get this fixed for 3.0.1?

Not sure... still need to work on it

New issue #920 opened on the same.

Issue #920 was reduced to address the security issue. Support of quoted identifiers is required to fix this issue. Case-sensitivity is just one issue, special characters like spaces need the very same treatment. In some cases the quotes must be removed (e.g. for querying the data dictionary views) and in other cases they have to be kept (e.g. when calling a package). This requires significant change in the framework.

What is the real use case for this requirement? Why do we need to support quoted identifiers (case sensitive names) exactly?

@PhilippSalvisberg
I don't think there is real need to support unit tests with quoted identifiers.
I do see however a potential for great simplification of package specification if we allow them.

Today, you need to do something like this:

create or replace package test_annot_disabled_reason as
  --%suite(annotations - disabled)
  --%suitepath(utplsql.ut3_tester.core.annotations)


  --%test(Disable all tests under the suite displaying suite level reason)
  procedure test_disable_on_suite_level;

  --%test(Disable all tests under one of two contexts displaying context level reason)
  procedure test_dis_on_1st_ctx_level;

  --%test(Disable a single tests from each of the contexts displaying test level reason)
  procedure test_disable_tests_level;

end;

While in fact you could do:

create or replace package "annotations - disabled" as
  --%suite
  --%suitepath(utplsql.ut3_tester.core.annotations)

  --%test
  procedure "Disable all tests under the suite displaying suite level reason";

  --%test
  procedure "Disable all tests under one of two contexts displaying context level reason";

  --%test
  procedure "Disable a single tests from each of the contexts displaying test level reason";

end;

I like the idea.

It shows a flaw with descriptions of tests. The description and the name of the test procedure might be completely different (which is bad when looking for the procedure in the code). Using quoted identifiers for test procedures can eliminate some need for descriptions. However, when I use contexts I name the procedures with the context prefix and avoid the repetition of the context in the test description to make the test output more terse. So, I still see cases where the description and name of the test procedure do not match.

Nevertheless, this approach simplifies a lot of cases and that's good.