Re: pgsql: Add more SQL/JSON constructor functions
jian he <jian.universality@gmail.com>
On Tue, Jul 30, 2024 at 12:59 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> Hi,
>
> On Fri, Jul 26, 2024 at 11:19 PM jian he <jian.universality@gmail.com> wrote:
> > On Fri, Jul 26, 2024 at 4:53 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > >
> > >
> > > Pushed 0003-0005 ahead of 0001-0002. Will try to push them over the
> > > weekend. Rebased for now.
>
> Pushed them now.
>
> > {
> > ...
> > /*
> > * For expression nodes that support soft errors. Should be set to NULL
> > * before calling ExecInitExprRec() if the caller wants errors thrown.
> > */
> > ErrorSaveContext *escontext;
> > } ExprState;
> >
> > i believe by default makeNode will set escontext to NULL.
> > So the comment should be, if you want to catch the soft errors, make
> > sure the escontext pointing to an allocated ErrorSaveContext.
> > or maybe just say, default is NULL.
> >
> > Otherwise, the original comment's meaning feels like: we need to
> > explicitly set it to NULL
> > for certain operations, which I believe is false?
>
> OK, I'll look into updating this.
>
> > struct
> > {
> > Oid targettype;
> > int32 targettypmod;
> > bool omit_quotes;
> > bool exists_coerce;
> > bool exists_cast_to_int;
> > bool check_domain;
> > void *json_coercion_cache;
> > ErrorSaveContext *escontext;
> > } jsonexpr_coercion;
> > do we need to comment that "check_domain" is only used for JSON_EXISTS_OP?
>
> I've renamed it to exists_check_domain and added a comment that
> exists_* fields are relevant only for JSON_EXISTS_OP.
>
> > json_behavior_type:
> > ERROR_P { $$ = JSON_BEHAVIOR_ERROR; }
> > | NULL_P { $$ = JSON_BEHAVIOR_NULL; }
> > | TRUE_P { $$ = JSON_BEHAVIOR_TRUE; }
> > | FALSE_P { $$ = JSON_BEHAVIOR_FALSE; }
> > | UNKNOWN { $$ = JSON_BEHAVIOR_UNKNOWN; }
> > | EMPTY_P ARRAY { $$ = JSON_BEHAVIOR_EMPTY_ARRAY; }
> > | EMPTY_P OBJECT_P { $$ = JSON_BEHAVIOR_EMPTY_OBJECT; }
> > /* non-standard, for Oracle compatibility only */
> > | EMPTY_P { $$ = JSON_BEHAVIOR_EMPTY_ARRAY; }
> > ;
> >
> > EMPTY_P behaves the same as EMPTY_P ARRAY
> > so for function GetJsonBehaviorConst, the following "case
> > JSON_BEHAVIOR_EMPTY:" is wrong?
> >
> > case JSON_BEHAVIOR_NULL:
> > case JSON_BEHAVIOR_UNKNOWN:
> > case JSON_BEHAVIOR_EMPTY:
> > val = (Datum) 0;
> > isnull = true;
> > typid = INT4OID;
> > len = sizeof(int32);
> > isbyval = true;
> > break;
> >
> > also src/backend/utils/adt/ruleutils.c
> > if (jexpr->on_error->btype != JSON_BEHAVIOR_EMPTY)
> > get_json_behavior(jexpr->on_error, context, "ERROR");
>
> Something like the attached makes sense? While this meaningfully
> changes the deparsing output, there is no behavior change for
> JsonTable top-level path execution. That's because the behavior when
> there's an error in the execution of the top-level path is to throw it
> or return an empty set, which is handled in jsonpath_exec.c, not
> execExprInterp.c.
>
hi amit.
seems you forgot to attach the patch?
Commits
-
SQL/JSON: Avoid initializing unnecessary ON ERROR / ON EMPTY steps
- 77aebe9a8d3c 17.0 landed
- dd8bea88abf4 18.0 landed
- 3a97460970f3 18.0 landed
- e4e27976a687 17.0 landed
-
SQL/JSON: Fix default ON ERROR behavior for JSON_TABLE
- 446d5ad7ae7d 17.0 landed
- bbd4c058a89b 18.0 landed
- 5067c230b8ee 17.0 landed
- 565caaa79af9 18.0 landed
-
SQL/JSON: Fix JSON_TABLE() column deparsing
- cd680b39211c 17.0 landed
- ee75a03f37fc 18.0 landed
- c88ce386c4d7 17.0 landed
- 68222851d5a8 18.0 landed
-
Update comment about ExprState.escontext
- fe323438140f 17.0 landed
- 3422f5f93fcf 18.0 landed
-
SQL/JSON: Fix casting for integer EXISTS columns in JSON_TABLE
- f95c5090d975 17.0 landed
- 7f56eaff2fb0 18.0 landed
-
SQL/JSON: Some fixes to JsonBehavior expression casting
- 847ee701bd3a 17.0 landed
- 74c96699be3f 18.0 landed
-
SQL/JSON: Remove useless code in ExecInitJsonExpr()
- 6f9a62b454e8 18.0 landed
- 8a1a4087bd5f 17.0 landed
-
SQL/JSON: Respect OMIT QUOTES when RETURNING domains over jsonb
- 3c3ccd4ca801 17.0 landed
- 4fc6a555606d 18.0 landed
-
SQL/JSON: Improve error-handling of JsonBehavior expressions
- d1dc4ae5608d 17.0 landed
- 231b7d670b21 18.0 landed
-
SQL/JSON: Fix error-handling of some JsonBehavior expressions
- 79fa052e7880 17.0 landed
- 63e6c5f4a2ee 18.0 landed
-
SQL/JSON: Rethink c2d93c3802b
- 86d33987e8b0 18.0 landed
- 2177306a6413 17.0 landed
-
SQL/JSON: Always coerce JsonExpr result at runtime
- 716bd12d22c5 17.0 landed
-
SQL/JSON: Fix coercion of constructor outputs to types with typmod
- c2d93c3802b2 17.0 landed