Re: pgsql: Add more SQL/JSON constructor functions - Mailing list pgsql-hackers

On Mon, Jul 1, 2024 at 6:45 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Sun, Jun 30, 2024 at 3:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > >> +    /*
> > >> +     * For domains, consider the base type's typmod to decide whether to setup
> > >> +     * an implicit or explicit cast.
> > >> +     */
> > >> +    if (get_typtype(returning->typid) == TYPTYPE_DOMAIN)
> > >> +            (void) getBaseTypeAndTypmod(returning->typid, &baseTypmod);
> >
> > > TBH I'm not super clear on why we decide on explicit or implicit cast
> > > based on presence of a typmod.  Why isn't it better to always use an
> > > implicit one?
> >
> > Hmm ... there are a bunch of existing places that seem to have similar
> > logic, but they are all in new-ish SQL/JSON functionality, and I would
> > not be surprised if they are all wrong.  parse_coerce.c is quite
> > opinionated about what a domain's typtypmod means (see comments in
> > coerce_type() for instance); see also the logic in coerce_to_domain:
> >
> >      * If the domain applies a typmod to its base type, build the appropriate
> >      * coercion step.  Mark it implicit for display purposes, because we don't
> >      * want it shown separately by ruleutils.c; but the isExplicit flag passed
> >      * to the conversion function depends on the manner in which the domain
> >      * coercion is invoked, so that the semantics of implicit and explicit
> >      * coercion differ.  (Is that really the behavior we want?)
> >
> > I don't think that this SQL/JSON behavior quite matches that.
>
> The reason I decided to go for the implicit cast only when there is a
> typmod is that the behavior with COERCION_EXPLICIT is only problematic
> when there's a typmod because of this code in
> build_coercion_expression:
>
>         if (nargs == 3)
>         {
>             /* Pass it a boolean isExplicit parameter, too */
>             cons = makeConst(BOOLOID,
>                              -1,
>                              InvalidOid,
>                              sizeof(bool),
>                              BoolGetDatum(ccontext == COERCION_EXPLICIT),
>                              false,
>                              true);
>
>             args = lappend(args, cons);
>         }
>
> Yeah, we could have fixed that by always using COERCION_IMPLICIT for
> SQL/JSON but, as Jian said, we don't have a bunch of casts that these
> SQL/JSON functions need, which is why I guess we ended up with
> COERCION_EXPLICIT here in the first place.
>
> One option I hadn't tried was using COERCION_ASSIGNMENT instead, which
> seems to give coerceJsonFuncExpr() the casts it needs with the
> behavior it wants, so how about applying the attached?

you patched works.
i think it's because of you mentioned build_coercion_expression `  if
(nargs == 3)` related code
and

find_coercion_pathway:
if (result == COERCION_PATH_NONE)
{
if (ccontext >= COERCION_ASSIGNMENT &&
TypeCategory(targetTypeId) == TYPCATEGORY_STRING)
result = COERCION_PATH_COERCEVIAIO;
else if (ccontext >= COERCION_EXPLICIT &&
TypeCategory(sourceTypeId) == TYPCATEGORY_STRING)
result = COERCION_PATH_COERCEVIAIO;
}

functions: JSON_OBJECT,JSON_ARRAY, JSON_ARRAYAGG,JSON_OBJECTAGG,
JSON_SERIALIZE
the returning type can only be string type or json. json type already
being handled in other code.
so the targetTypeId category will be only TYPCATEGORY_STRING.