Re: [HACKERS] psql - add special variable to reflect the last query status

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] psql - add special variable to reflect the last query status
Дата
Msg-id CAFj8pRCDj96i-XRLS0g-SCe6S4mJD9m==+0e7HhkRGRau=nZnw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] psql - add special variable to reflect the last query status  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers


2017-09-12 20:43 GMT+02:00 Robert Haas <robertmhaas@gmail.com>:
On Tue, Sep 12, 2017 at 1:23 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
> I added two error codes, which is debatable. One is used hardcoded by libpq
> if no diagnostic is found, and the other by psql if libpq returned something
> empty, which might happen if psql is linked with an older libpq, maybe. I do
> not know how to trigger such errors anyway, so this is rather academic.

I think this is a bad plan.  Right now, libpq sets no SQLSTATE for
internally generated errors; it is almost certain that there are
applications testing for an empty SQLSTATE to notice when they're
getting an error from libpq.  EnterpriseDB had a support ticket quite
recently where this precise behavior was at issue.  Changing it will
break stuff, so we shouldn't do it unless there's a really compelling
benefit.  Universally returning PQ000 is not a sufficient improvement
over universally returning the empty string to justify the risk of
application breakage.

+1

Pavel
 

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] psql - add special variable to reflect the last query status
Следующее
От: Andreas Joseph Krogh
Дата:
Сообщение: Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10(upgrading standby servers)