| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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-12 19:35:06 |
| Message-ID: | alpine.DEB.2.20.1709122125570.4555@lancre |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> Well, if we provided a different SQLSTATE for each qualitatively
>> different type of libpq error, that might well be useful enough to
>> justify some risk of application breakage. But replacing a constant
>> string that we've had for ~15 years with a different constraint string
>> isn't doing anything about the lack-of-information problem you're
>> complaining about.
>
> True. Well, the original point here was whether psql ought to be doing
> something to mask libpq's (mis) behavior. I'm inclined to think not:
> if it doesn't get a SQLSTATE from the PGresult, it should just set the
> sqlstate variables to empty strings.
See v9 attached.
--
Fabien.
| Attachment | Content-Type | Size |
|---|---|---|
| psql-result-status-9.patch | text/x-diff | 16.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-09-12 19:36:46 | Re: DROP SUBSCRIPTION hangs if sub is disabled in the same transaction |
| Previous Message | Jaime Casanova | 2017-09-12 19:35:05 | Re: generated columns |