Using package constants in package SQL - acts as bind variable or literal?

Question

I'm looking for confirmation on the performance impact of using package constants in package SQL.
Let's say I have a number of queries in package code that refer to various literals that are prone to typos e.g. "CANCELLED" instead of "CANCELED". To reduce the chances of this happening, I have an APP_GLOBALS package where I declare constants for each literal:
C_CANCELED CONSTANT VARCHAR2(12) := 'CANCELED';And in queries that refer to literal 'CANCELED' I use APP_GLOBALS.C_CANCELED instead. This way the typo is caught during compilation. For example:
BEGIN
--Do something with all 'Canceled' orders
  FOR r IN (SELECT order_id
              FROM orders
             WHERE status = APP_GLOBALS.C_CANCELED)
  LOOP
  END LOOP;
END;Assume that:
- the STATUS column is indexed
- the possible values are PENDING, APPROVED, CANCELED
- a small percentage of orders are CANCELED
From the optimizer's perspective is the query equivalent to
SELECT order_id
  FROM orders
WHERE status = :varor
SELECT order_id
  FROM orders
WHERE status = 'CANCELED'?
According to what I see in v$sqltext_with_newlines, it's the first one. Can anyone suggest an alternative way of replacing literals in package SQL to prevent typos? Worst case, I suppose I can start with constants so that it compiles successfully then do a global replace of the constants with the literals.

Answer 1

Can anyone suggest an alternative way of replacing literals in package SQL to prevent typos?I cannot think of any. But, here is the thing. If the typos are there, then, it technically is a bug even though both the codes would compile. The bug will be hunted down when the program doesn't work as intended. Wouldn't most typos be caught in unit testing of the code?
Also, if you replace a string literal with a variable, then, maybe (just maybe, depending on your version of the dbms), it may end up picking a different execution plan. That might be an unintended consequence.