Mention column name in error messages

From: Franck Verrot <franck(at)verrot(dot)fr>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Mention column name in error messages
Date: 2015-06-29 13:46:48
Message-ID: CANfkH5k-6nNt-4cSv1vPB80nq2BZCzhFVR5O4VznYbsX0wZmow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

As far as I know, there is currently no way to find which column is triggering
an error on an INSERT or ALTER COLUMN statement. Example:

# create table foo(bar varchar(4), baz varchar(2));
CREATE TABLE
# insert into foo values ('foo!', 'ok');
INSERT 0 1
# insert into foo values ('foo2!', 'ok');
ERROR: value too long for type character varying(4)
# insert into foo values ('foo!', 'ok2');
ERROR: value too long for type character varying(2)

I browsed the list and found a conversation from last year
(http://www.postgresql.org/message-id/3214.1390155040@sss.pgh.pa.us) that
discussed adding the actual value in the output.

The behavior I am proposing differs in the sense we will be able to see in
the "ERROR: xxxx" what column triggered the error:

# create table foo(bar varchar(4), baz varchar(2));
CREATE TABLE
# insert into foo values ('foo!', 'ok');
INSERT 0 1
# insert into foo values ('foo2!', 'ok');
ERROR: value too long for bar of type character varying(4)
# insert into foo values ('foo!', 'ok2');
ERROR: value too long for baz of type character varying(2)

In that same conversation, Tom Lane said:

> [...] People have speculated about ways to
> name the target column in the error report, which would probably be
> far more useful; but it's not real clear how to do that in our system
> structure.

Given my very restricted knowledge of PG's codebase I am not sure whether my
modifications are legitimate or not, so please don't hesitate to comment on
it and pointing where things are subpar to PG's codebase. In any case, it's
to be considered as WIP for the moment.

Thanks in advance,
Franck

--
Franck Verrot
https://github.com/franckverrot
https://twitter.com/franckverrot

Attachment Content-Type Size
verbose-validation.patch application/octet-stream 22.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2015-06-29 13:48:52 Re: drop/truncate table sucks for large values of shared buffers
Previous Message Michael Paquier 2015-06-29 13:11:57 Re: In-core regression tests for replication, cascading, archiving, PITR, etc.