BUG #15666: Seemingly incorrect error reporting/logging for violation of non-null constraint
The following bug has been logged on the website:
Bug reference: 15666
Logged by: Dirkjan Ochtman
Email address: dirkjan@ochtman.nl
PostgreSQL version: 11.2
Operating system: Linux
Description:
I'm modifying the data model for the application I work on, and in the
process of doing so, I'm seeing this error:
db | 2019-03-04 09:48:54.485 UTC [198] ERROR: null value in column
"accountid" violates not-null constraint
db | 2019-03-04 09:48:54.485 UTC [198] DETAIL: Failing row contains
(14, 138962.38, 0, null, 13).
db | 2019-03-04 09:48:54.485 UTC [198] STATEMENT: insert into
JournalEntryRecord (accountId, amount, journalEntryId, type, id) values ($1,
$2, $3, $4, $5)
This is very confusing to me because the tuple from the "Failing row"
message clearly has the `null` in fourth position, but the error message
reports that the column "accountid" (or "accountId" -- but I understand
column names are casefolded) is the problem, which should ostensibly be the
first value from the failing row tuple (if that tuple is ordered the same
way as the statement suggests).
PG Bug reporting form <noreply@postgresql.org> writes:
I'm modifying the data model for the application I work on, and in the
process of doing so, I'm seeing this error:
db | 2019-03-04 09:48:54.485 UTC [198] ERROR: null value in column
"accountid" violates not-null constraint
db | 2019-03-04 09:48:54.485 UTC [198] DETAIL: Failing row contains
(14, 138962.38, 0, null, 13).
db | 2019-03-04 09:48:54.485 UTC [198] STATEMENT: insert into
JournalEntryRecord (accountId, amount, journalEntryId, type, id) values ($1,
$2, $3, $4, $5)
This is very confusing to me because the tuple from the "Failing row"
message clearly has the `null` in fourth position, but the error message
reports that the column "accountid" (or "accountId" -- but I understand
column names are casefolded) is the problem, which should ostensibly be the
first value from the failing row tuple (if that tuple is ordered the same
way as the statement suggests).
Well, maybe it isn't. That DETAIL line would report all the columns of the
table, in their physical order. That doesn't necessarily have anything to
do with the original INSERT, which --- if it has a column list, as this
does --- can choose to target any subset of the columns in any order.
We can't very well order the DETAIL to match the original INSERT, since
it's entirely possible that the complaint is about a column not even
mentioned in the INSERT.
regards, tom lane
On Mon, Mar 4, 2019 at 3:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Well, maybe it isn't. That DETAIL line would report all the columns of the
table, in their physical order. That doesn't necessarily have anything to
do with the original INSERT, which --- if it has a column list, as this
does --- can choose to target any subset of the columns in any order.We can't very well order the DETAIL to match the original INSERT, since
it's entirely possible that the complaint is about a column not even
mentioned in the INSERT.
That makes sense to me. Maybe it would be feasible to label the failing row
values with their column's name?
It also might be just my brain being paranoid -- not sure if others find
this as confusing as I did.