On Tue, Aug 23, 2022 at 11:55 AM Andres Freund <and...@anarazel.de> wrote: > I don't think that's quite realistic - that's the input/output functions for > all types, basically. I'd be somewhat content if we'd a small list of very > common coercion paths we knew wouldn't error out, leaving things like OOM > aside. Even just knowing that for ->text conversions would be a huge deal in > the context of this patch. One problem here is that the whole type coercion > infrastructure doesn't make it easy to know what "happened inside" atm, one > has to reconstruct it from the emitted expressions, where there can be > multiple layers of things to poke through.
But that's exactly what I'm complaining about. Catching an error that unwound a bunch of stack frames where complicated things are happening is fraught with peril. There's probably a bunch of errors that could be thrown from somewhere in that code - out of memory being a great example - that should not be caught. What you (probably) want is to know whether one specific error happened or not, and catch only that one. And the error machinery isn't designed for that. It's not designed to let you catch specific errors for specific call sites, and it's also not designed to be particularly efficient if lots of errors need to be caught over and over again. If you decide to ignore all that and do it anyway, you'll end up with, at best, code that is complicated, hard to maintain, and probably slow when a lot of errors are trapped, and at worst, code that is fragile or outright buggy. -- Robert Haas EDB: http://www.enterprisedb.com
