Обсуждение: BUG #15666: Seemingly incorrect error reporting/logging for violation of non-null constraint
BUG #15666: Seemingly incorrect error reporting/logging for violation of non-null constraint
От
PG Bug reporting form
Дата:
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
Re: BUG #15666: Seemingly incorrect error reporting/logging forviolation of non-null constraint
От
Dirkjan Ochtman
Дата:
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.