On Mon, Jan 27, 2020 at 11:07 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > I have not, but I'm still going to stand by that point. It is not > credible that the code we will want to share between frontend and > backend will never contain any user-facing error reports.
It's hard to refute a statement this general; it can only devolve into an argument about what we will want to do in the future. And, if I may be permitted to appeal to a highier authority on that topic, I think this quote is highly relevant: "Difficult to see. Always in motion is the future." What I was hoping to do in this thread was to focus on the problem of which I have several instances immediately at hand, which is handling can't-happen conditions, rather than blowing open the issue in its full generality. I think there is a meaningful amount of code in the backend where that is, or can be made to be, the only issue that needs to be solved, and I therefore think that it is a reasonable special case to tackle first. Of course, I can't force you to have that conversation, but I don't think refusing to have it is going to make the problem go away. Realistically, people aren't going to stop moving code to src/common; what they're going to do is put special-case hacks in each file, like we already have in a couple of places, instead of using some more general solution upon which we might try to agree. In other words, somebody who comes across a chunk of code that uses ereport() extensively might conceivably give up on moving it to src/common, but somebody who finds one elog(ERROR, "oops this is broken") is not going to for that reason give up. They are going to do something to get around it. Better for them all to do the same thing, and something that's had some general thought given to it, than for each person who runs into such a problem to hand-roll their own way of handling it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company