dan>This is documented in the javadoc for DatabaseMetaData , e.g. "tableNamePattern - a table name pattern; must match the table name as it is stored in the database" If
DERBY-2092 was addressed then it would be part of Derby's documentation set.
I was surprised that there was no mention of this implementation detail anywhere in the reference guide, i.e. the reference guide never mentions what is 'the table name as it is stored in the database' as far as I can tell. The actual behavior itself was not surprising, just ran into it after passing around schema / tablenames as Strings and ending up with empty ResultSets for some DatabaseMetaData methods in some cases, so I checked the docs and did not find it mentioned there.
dan> I didn't understand this paragraph, not sure what a "universal test" is, and this comment lost me "grant and have references privilege on a column for which it has no meaning to have that privilege"
Sorry, it was late and I could have been more clear here. It is possible to grant references privilege on any column, not just primary keys or unique constraints. You can grant references on any column in the database, and Derby happily records that privilege, and you can see in the test that this privilege on the column can be confirmed from the metadata.
I checked the SQL standard, grant for references seems to be allowed to be granted on arbitrary tables / columns in case those table / columns in the grant are at some point modified to have / be a primary key or have a unique constraint placed on them. However, having the privilege doesn't mean you can do anything useful with it without a primary key or unique constraint on the table / column, and there's no way to check the use of it without modifying the original table. i.e. in the style of the test:
"create table foo (c1 int not null primary key, c2)"
passes if you just check the metadata for the privilege, but you can't test in the assert method that you have references privilege on c2 without modifying table foo in the assert method. I feel this sort of violates the spirit of the assert tests, in that they shouldn't be changing the state of the things being asserted, just verifying their state. It's probably also why this check in the previous test was left stubbed out, since there's no good check for it that doesn't alter the original table's definition.
It's not a problem, just making a note of it for the next person who comes along and wonders what is going on here. I'll go back and double-check the comments in the test to make sure they are clear.