Here is the 5th version of this patch.
As I suspected first, the errors in some tests are caused by the fact that ij now reports the connection as part as the identifier when an error in encountered.
As you noticed here, this slightly breaks the observable behavior of ij. But I think from an user point of view it is important to report the connection name as well as the unqualified identifier in order to clearly distinguish a faulty statement.
I chose to update all the related tests in order to reflect that. Here are some examples of such changes (extract from the attached patch):
-IJ ERROR: Unable to establish cursor
+IJ ERROR: Unable to establish cursor JDK4@CONNECTION0
-IJ ERROR: Unable to establish prepared statement P1
+IJ ERROR: Unable to establish prepared statement P1@CONNECTION0
Now pass the following tests without any error:
java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
java org.apache.derbyTesting.functionTests.harness.RunSuite derbytools
java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.lang.LangScripts
java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.tools.ToolScripts
Concerning a possible use of qualified identifiers in the PROTOCOL statement:
I didn't notice a previous comment on this:
> 3) Connection-scoped variables. These include the names of prepared statements, cursors, and protocols.
In fact, protocols are not connection-scoped: protocols identifiers are currently bound the parser instance, not to a session object. It feels like some kind of global identifier to me. Moreover, the PROTOCOL statement could be issued before opening any connection (i.e.: before any session object was available):
sh$ java org.apache.derby.tools.ij
ij version 10.6
ij> PROTOCOL 'jdbc:derby:memory:' AS memory;
ij> CONNECT 'a;create=true;user=fred' PROTOCOL memory;
ij> CONNECT 'b;create=true' PROTOCOL memory;
Please note I never really used that statement, so it's quite possible I missed some important point here.
An other possible candidate for qualified identifiers could be the DESCRIBE statement. But I think this is part of an other issue, since DESCRIBE requires some special treatment (it uses its own production caIdentifier).