Re: SQL/JSON revisited

On Wed, Dec 28, 2022 at 4:28 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>
> Hi,
>
> Rebased the SQL/JSON patches over the latest HEAD. I've decided to
> keep the same division of code into individual commits as that
> mentioned in the revert commit 2f2b18bd3f, squashing fixup commits in
> that list into the appropriate feature commits.
>
> The main difference from the patches as they were committed into v15
> is that JsonExpr evaluation no longer needs to use sub-transactions,
> thanks to the work done recently to handle type errors softly. I've
> made the new code pass an ErrorSaveContext into the type-conversion
> related functions as needed and also added an ExecEvalExprSafe() to
> evaluate sub-expressions of JsonExpr that might contain expressions
> that call type-conversion functions, such as CoerceViaIO contained in
> JsonCoercion nodes. ExecExprEvalSafe() is based on one of the patches
> that Nikita Glukhov had submitted in a previous discussion about
> redesigning SQL/JSON expression evaluation [1]. Though, I think that
> new interface will become unnecessary after I have finished rebasing
> my patches to remove subsidiary ExprStates of JsonExprState that we
> had also discussed back in [2].

And I've just finished doing that. In the attached updated 0004,
which adds the JsonExpr node, its evaluation code is now broken into
ExprEvalSteps to handle the subsidiary JsonCoercion and JsonBehavior
expression nodes that previously used ExprState for recursive
evaluation. Andres didn't like the latter as previously discussed at
[1].

I've also attached the patch that Elena has proposed as the patch
0011. I haven't managed to review it yet, though once I do, I'll
merge it into the main documentation patch 0009. Thanks Elena.

--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com

[1] https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de