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