Re: SQL/JSON features for v15

Hi,

On 2022-08-23 13:33:42 -0400, Robert Haas wrote:
> On Tue, Aug 23, 2022 at 1:23 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > 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.
> >
> > The code as is handles this to some degree. Only ERRCODE_DATA_EXCEPTION,
> > ERRCODE_INTEGRITY_CONSTRAINT_VIOLATION are caught, the rest is immediately
> > rethrown.
>
> AFAIK, Tom has rejected every previous effort to introduce this type
> of coding into the tree rather forcefully. What makes it OK now?

I didn't say it was! I don't like it much - I was just saying that it handles
that case to some degree.

> > I'm not sure what the general alternative is though. Part of the feature is
> > generating a composite type from json - there's just no way we can make all
> > possible coercion pathways not error out. That'd necessitate requiring all
> > builtin types and extensions types out there to provide input functions that
> > don't throw on invalid input and all coercions to not throw either. That just
> > seems unrealistic.
>
> Well, I think that having input functions report input that is not
> valid for the data type in some way other than just chucking an error
> as they'd also do for a missing TOAST chunk would be a pretty sensible
> plan. I'd support doing that if we forced a hard compatibility break,
> and I'd support that if we provided some way for old code to continue
> running in degraded mode. I haven't thought too much about the
> coercion case, but I suppose the issues are similar. What I don't
> support is saying -- well, upgrading our infrastructure is hard, so
> let's just kludge it.

I guess the 'degraded mode' approach is kind of what I was trying to describe
with:

> I think the best we could without subtransactions do perhaps is to add
> metadata to pg_cast, pg_type telling us whether certain types of errors are
> possible, and requiring ERROR ON ERROR when coercion paths are required that
> don't have those options.

Greetings,

Andres Freund