Column name on NOT NULL constaint violation not shown I'm using an Oracle 19 DB that is structured into multiple layers by using DB users. Here is a simplified overview of the structure:

User DATA: Has the table XTEST and the view TEST. The view is created with a CREATE VIEW TEST AS SELECT * FROM XTEST statement, so it contains all columns of the table.
User APP: Uses the view DATA.TEST for all SQL and DML.
The APP user does not have any grants on the table DATA.XTEST, but does have SELECT,INSERT,UPDATE,DELETE grants on the view DATA.TEST.

Now to my problem:
If a NOT NULL constraint on the table DATA.XTEST is violated, the error message doesn't show the column name. The error message is literally:

ORA-01400: cannot insert NULL into (???)

The DB used Oracle 11 some time ago and back then we had the same problem, but could fix it by granting the REFERENCES privilege on the table DATA.XTEST to the APP user (see related question: Grant privilege to see column names in null constraint violations when inserting in views). But this doesn't work any more in Oracle 19.
Does anyone know how to get the column name in the error message?
There is a security consequence to setting SQL92_SECURITY to false.
From https://www.stigviewer.com/stig/oracle_database_12c/2020-04-01/finding/V-61429

The configuration option SQL92_SECURITY specifies whether table-level
SELECT privileges are required to execute an update or delete that
references table column values. If this option is disabled (set to
FALSE), the UPDATE privilege can be used to determine values that
should require SELECT privileges. The SQL92_SECURITY setting of TRUE
prevents the exploitation of user credentials with only DELETE or
UPDATE privileges on a table from being able to derive column values
in that table by performing a series of update/delete statements using
a where clause, and rolling back the change.
In the following example, with SQL92_SECURITY set to FALSE, a user
with only delete privilege on the scott.emp table is able to derive
that there is one employee with a salary greater than 3000. With
SQL92_SECURITY set to TRUE, that user is prevented from attempting to
derive a value.

SQL92_SECURITY = FALSE
SQL&gt; delete from scott.emp where sal &gt; 3000; 

1 row deleted 

SQL&gt; rollback; 

Rollback complete 

SQL92_SECURITY = TRUE
SQL&gt; delete from scott.emp where sal &gt; 3000; 

delete from scott.emp where sal &gt; 3000 * 

ERROR at line 1: ORA-01031: insufficient privileges

If this is a concern for you, then consider using a PL/SQL API package to make changes to your table, rather than granting access directly to the user. See &quot;Guarding Your Data Behind a Hard Shell PL/SQL API&quot; for reference. Also see here: https://www.youtube.com/watch?reload=9&amp;v=GZUgey3hwyI. A singleton package with definers rights could raise the error back to the app without granting excessive privileges or altering the overall security posture of your system.