Re: Mention column name in error messages

From: Franck Verrot <franck(at)verrot(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Mention column name in error messages
Date: 2016-11-06 20:20:37
Message-ID: CANfkH5=8OjF4k9VPXjzOeyeM70TN69PjvW7eSy6CAgJX5a9n0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 5, 2016 at 11:13 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> The cases that are successfully annotated by the current patch seem to
> mostly already have error cursor information, which really is good enough
> IMO --- you can certainly figure out which column corresponds to the
> textual spot that the cursor is pointing at.

The original intent of that patch tried to cover the case where we insert
records
made of dozens columns sharing the same type definition, and trying to
understand
what is going on, at a glance, when we debugged something like this:

# create table probes (
id int,
pin_1 varchar(2),
pin_2 varchar(2),
...
pin_19 varchar(2),
pin_20 varchar(2));
CREATE TABLE

# insert into probes (
pin_1,
pin_2,
...
pin_19,
pin_20)
values ( <only valid values> );
INSERT 0 1

# insert into probes (
pin_1,
pin_2,
...
pin_19,
pin_20)
values ( <values, some subjects to type casting errors> );
ERROR: value too long for type character varying(2)

Relying on the cursor seems to be of little help I'm afraid.

Thanks for having looked into that, very useful to try understanding all
the mechanisms that are involved to make that happen.

Franck

--
Franck Verrot

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Guillaume Lelarge 2016-11-06 20:33:20 Re: Exclude pg_largeobject form pg_dump
Previous Message Tom Lane 2016-11-06 18:15:28 Re: Add support for SRF and returning composites to pl/tcl