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 |
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. |