On Tue, Sep 12, 2017 at 1:23 PM, Fabien COELHO <coe...@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
