Remove DBMS_LOCK grant from shared setup; keep it only for 11g

[yahonda]

Summary

• Remove grant execute on dbms_lock to hr from spec/support/unlock_and_setup_hr_user.sql
• Add the grant only to the test_11g.yml workflow where Oracle 11g still needs DBMS_LOCK.SLEEP

DBMS_SESSION.SLEEP (available since Oracle 18c) does not require a separate grant from SYS. The spec already prefers DBMS_SESSION.SLEEP on Oracle 18c+ and falls back to DBMS_LOCK.SLEEP on older versions, so no spec changes are needed.

Test plan

• test.yml (Oracle Free 23) passes without the DBMS_LOCK grant
• test_11g.yml passes with the DBMS_LOCK grant added in the workflow

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Moves the DBMS_LOCK execute grant out of the shared HR user setup script and scopes it to the Oracle 11g CI workflow where the test suite still needs DBMS_LOCK.SLEEP.

Changes:

• Removed GRANT EXECUTE ON DBMS_LOCK from the shared unlock_and_setup_hr_user.sql setup.
• Added an Oracle 11g-only workflow step to grant DBMS_LOCK execute to hr.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
spec/support/unlock_and_setup_hr_user.sql	Removes the global DBMS_LOCK grant so newer DBs don’t require SYS-level privileges unnecessarily.
.github/workflows/test_11g.yml	Adds back the DBMS_LOCK grant only in the 11g CI job where it’s needed.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This step may not actually fail the workflow if the GRANT errors. SQLPlus commonly exits with status 0 unless instructed otherwise, so an ORA- error (e.g., insufficient privileges) could be missed and the job would proceed. Consider running SQL*Plus with a script that includes whenever sqlerror exit sql.sqlcode; (and an explicit exit;) so the step reliably fails on grant errors.

Suggested change

	echo "GRANT EXECUTE ON DBMS_LOCK TO hr;" | sqlplus system/${DATABASE_SYS_PASSWORD}@${DATABASE_NAME}
	cat <<'SQL' | sqlplus system/${DATABASE_SYS_PASSWORD}@${DATABASE_NAME}
	whenever sqlerror exit sql.sqlcode;
	GRANT EXECUTE ON DBMS_LOCK TO hr;
	exit;
	SQL

[Copilot]

The GRANT is executed while connected as system but uses a variable named DATABASE_SYS_PASSWORD, which is inconsistent and can be incorrect for granting on SYS-owned packages in some Oracle setups. If this grant requires SYS/SYSDBA in your 11g environment, connect as sys ... as sysdba (or use the correct credential variable for system) to avoid privilege-related flakiness.

Suggested change

	echo "GRANT EXECUTE ON DBMS_LOCK TO hr;" | sqlplus system/${DATABASE_SYS_PASSWORD}@${DATABASE_NAME}
	echo "GRANT EXECUTE ON DBMS_LOCK TO hr;" | sqlplus "sys/${DATABASE_SYS_PASSWORD}@${DATABASE_NAME} as sysdba"

[yahonda]

I'm closing this as I've reconsidered and think I'm overcomplicating it.