Re: Any hope for more specific error message for "value too long..."?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Any hope for more specific error message for "value too long..."?
Date: 2018-02-17 16:26:12
Message-ID: 20105.1518884772@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com> writes:
>>> I dug in the archives and came across a crude POC hack here:
>>> https://www.postgresql.org/message-id/21693.1478376334@sss.pgh.pa.us
>> For that matter, it's not totally
>> clear what would constitute an improvement --- what do you wish it would
>> show you, exactly?

> It looks like that patch is about showing which value or where in the
> statement the error is being caused. At least for my case, it would be
> helpful to know which field is causing the error. And just guessing, but
> maybe simpler?

No; read the rest of that thread. It would actually be nigh impossible to
do it that way in the current system, except for a small subset of cases.
Furthermore, if we did do it like that, what about similar errors in
non-INSERT commands? The error cursor approach at least has the advantage
of being pretty generically applicable. In principle we could make it
work for any error arising during expression evaluation.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Olegs Jeremejevs 2018-02-17 19:31:16 Re: Rationale for PUBLIC having CREATE and USAGE privileges on the schema "public" by default
Previous Message Abhra Kar 2018-02-17 15:15:36 Re: postgres connection with port option in shell script