From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | bricklen <bricklen(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Inspect values of prepared statements |
Date: | 2016-05-03 00:13:57 |
Message-ID: | CAKFQuwak+q-sedmYESgbkQv0thc=HYUjFB1UUwtAmx9Ug71QKw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Mon, May 2, 2016 at 4:17 PM, bricklen <bricklen(at)gmail(dot)com> wrote:
>
> On Mon, May 2, 2016 at 2:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> What I think we could do without too much trouble or overhead is to set
>> up errcontext data so that a failure like that could come with a CONTEXT
>> line like
>>
>> ERROR: invalid input syntax for type double precision: "A"
>> STATEMENT: insert into x (a,b,c,d,e,f) VALUES ($1,$2,$3,$4,$5,$6)
>> CONTEXT: reading parameter $2 for statement "foo"
>>
>> I'm curious whether that would be enough information to solve your
>> problem.
>>
>
> I ran into this same problem a couple weeks ago, your suggestion above
> would have supplied enough information to debug the invalid input without
> having to jump through hoops at the application side.
>
Agreed. The times I encounter this I get hung up is figuring out which of
5 identically typed columns might be presenting the problem - typically
because of an empty string error so searching is somewhat more tedious.
If reporting the number is low-hanging fruit it is definitely worth picking
off.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Ondřej Světlík | 2016-05-04 15:08:34 | Autovacuum of pg_shdepend |
Previous Message | bricklen | 2016-05-02 23:17:51 | Re: Inspect values of prepared statements |