[sahvx655-wq]

PrimaryKeyFinder, which backs getPrimaryKeys, getExportedKeys and getImportedKeys, runs PK_NAMED_PATTERN over the table's CREATE statement from sqlite_schema with find(), and that pattern backtracks cubically whenever the DDL has no named primary key. Root cause: find() retries the leading .* from every offset, and from every CONSTRAINT keyword the lazy name group rescans to the end of the string. I found it while timing the metadata regexes against long schemas: a 10 KB CREATE TABLE with 400 CHECK constraints and a column-level primary key spends about 125 s in the regex (2.5 KB takes 2 s, 5 KB takes 13 s), so a tool calling getPrimaryKeys on a database file it did not create can be pinned on a single table, and ordinary schemas with a lot of checks are already noticeably slow.

Both patterns are now anchored with \A, which returns the same groups because a DOTALL leading .* matches from index 0 whenever it matches anywhere. The name group can no longer cross another CONSTRAINT keyword, which the greedy .* already rules out, and the DDL is cut after its last ) because both patterns need one after PRIMARY KEY. With that the same 10 KB DDL takes 0.16 ms and 1 MB takes about 17 ms; the old and new patterns gave identical groups across 1M random DDL fragments, and a 100k character constraint name does not overflow the stack on JDK 8, 11 or 21. The new DBMetaDataTest case times out after 10 s on master and passes with the fix. I left the unused copies of these patterns in CoreDatabaseMetaData alone.

[gotson]

nice work, thanks