On Tue, Sep 12, 2017 at 3:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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. > > I don't think I want to buy this argument, because the logical conclusion > of it is that we can never fix libpq to offer proper SQLSTATEs for > client-side errors. Admittedly, the fact that nobody's bothered to do so > in ~15 years may indicate that nobody cares ... but I would think that > at least it'd be useful to distinguish, say, ENOMEM from connection loss. > Saying we can't do it for compatibility reasons doesn't sound great > to me. Especially when you've not provided any hard evidence as to why > the current lack-of-information is useful.
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. -- 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
