| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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:46:27 |
| Message-ID: | alpine.DEB.2.20.1709112042050.8852@lancre |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>> 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.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-09-11 18:48:09 | Re: assorted code cleanup |
| Previous Message | Peter Eisentraut | 2017-09-11 18:26:15 | Re: DROP SUBSCRIPTION hangs if sub is disabled in the same transaction |