From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgsql: Add more SQL/JSON constructor functions |
Date: | 2024-07-01 10:45:11 |
Message-ID: | CA+HiwqGCQb+eajTRTQfnQjuvAoUJOC4SFhGJAXwqGzGsEHHi_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jun 30, 2024 at 3:56 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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?
--
Thanks, Amit Langote
Attachment | Content-Type | Size |
---|---|---|
v6-0001-SQL-JSON-Rethink-c2d93c3802b.patch | application/octet-stream | 2.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2024-07-01 10:49:07 | Re: Make tuple deformation faster |
Previous Message | Amit Kapila | 2024-07-01 10:44:56 | Re: New standby_slot_names GUC in PG 17 |