Re: SQL/JSON features for v15

On Tue, Aug 23, 2022 at 11:55 AM Andres Freund <andres(at)anarazel(dot)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