From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Joe Conway <mail(at)joeconway(dot)com>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Error-safe user functions |
Date: | 2022-12-10 15:43:28 |
Message-ID: | CAFj8pRBWPtLtg-H3zxHaFz6vFo4NmgmrJXtXsbRmg7RAaGZ-rQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
so 10. 12. 2022 v 15:35 odesílatel Andrew Dunstan <andrew(at)dunslane(dot)net>
napsal:
>
> On 2022-12-09 Fr 10:37, Andrew Dunstan wrote:
> > I am currently looking at the json types. I think that will be enough to
> > let us rework the sql/json patches as discussed a couple of months ago.
> >
>
> OK, json is a fairly easy case, see attached. But jsonb is a different
> kettle of fish. Both the semantic routines called by the parser and the
> subsequent call to JsonbValueToJsonb() can raise errors. These are
> pretty much all about breaking various limits (for strings, objects,
> arrays). There's also a call to numeric_in, but I assume that a string
> that's already parsed as a valid json numeric literal won't upset
> numeric_in. Many of these occur several calls down the stack, so
> adjusting everything to deal with them would be fairly invasive. Perhaps
> we could instead document that this class of input error won't be
> trapped, at least for jsonb. We could still test for well-formed jsonb
> input, just as I propose for json. That means that we would not be able
> to trap one of these errors in the ON ERROR clause of JSON_TABLE. I
> think we can probably live with that.
>
> Thoughts?
>
+1
Pavel
>
>
> cheers
>
>
> andrew
>
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>
From | Date | Subject | |
---|---|---|---|
Next Message | Corey Huinker | 2022-12-10 17:19:59 | Re: Error-safe user functions |
Previous Message | Andrew Dunstan | 2022-12-10 14:35:12 | Re: Error-safe user functions |