From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql - add special variable to reflect the last query status |
Date: | 2017-09-11 18:55:27 |
Message-ID: | CAFj8pRBAFBHhsZ-Z=owJRM8Bm4qLbvXT=Be88U0Jz4SN2FGxtw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2017-09-11 20:46 GMT+02:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:
>
> I think you're overly optimistic to believe that every failure will
>>>> have a SQLSTATE; I don't think that's true for libpq-reported errors,
>>>> such as connection loss.
>>>>
>>>
>> Yep, I thought I was optimistic:-) Can I add a special SQLSTATE for that
>>> situation where libpq did not report an error?
>>>
>>
>> Meh. If we're going to do that I think it might be better to hack
>> libpq itself to do so, ie, force PQresultErrorField(..., PG_DIAG_SQLSTATE)
>> to always return something. But it seems like a hack either way.
>>
>
> I would not have took the liberty to hack into libpq internals for such a
> small front-end feature. However I agree that having libpq always return
> some diagnostic, even if it means "something unclear happened, sorry not to
> be very precise", would be better.
probably better don't do it before somebody implements this are correctly
.. some temporary solution can introduce possible compatibility issues.
If SQLSTATE has not know value, then it should be NULL or maybe empty
string.
Pavel
>
>
> --
> Fabien.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2017-09-11 19:02:21 | Re: pgbench tap tests & minor fixes. |
Previous Message | Peter Eisentraut | 2017-09-11 18:48:09 | Re: assorted code cleanup |