2017-09-12 20:43 GMT+02:00 Robert Haas <robertmh...@gmail.com>: > 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. >
+1 Pavel > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
