From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: jian he <jian.universality@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pgsql: Add more SQL/JSON constructor functions
Date: Sat, 29 Jun 2024 14:56:15 -0400
Message-ID: <2232738.1719687375@sss.pgh.pa.us> (raw)
In-Reply-To: <202406291824.reofujy7xdj3@alvherre.pgsql>
References: <202406291824.reofujy7xdj3@alvherre.pgsql>
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.
While I'm bitching ... this coding style is bogus anyway:
>> + if (get_typtype(returning->typid) == TYPTYPE_DOMAIN)
>> + (void) getBaseTypeAndTypmod(returning->typid, &baseTypmod);
because it results in two syscache lookups not one. You are supposed
to apply getBaseTypeAndTypmod unconditionally, as is done everywhere
except in the SQL/JSON logic. I am also wondering how it can possibly
be sensible to throw away the function result of getBaseTypeAndTypmod
in this context.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, amitlangote09@gmail.com, jian.universality@gmail.com, peter@eisentraut.org, pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Add more SQL/JSON constructor functions
In-Reply-To: <2232738.1719687375@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox