Re: Proposal to adjust typmod argument on base UDT input functions

On 07/08/25 23:18, Tom Lane wrote:
>> That was my first thought as well, but COPY sends the typmod directly
>> already, so if they support COPY, they should already be compatible.
> COPY is not the same context.

The INPUT function is not context aware.

From Postgres documentation:
>  The input function can be declared as taking one argument of type
|cstring|, or as taking three
> arguments of types |cstring|, |oid|, |integer|. The first argument is
the input text as a C string, the
> second argument is the type's own OID (except for array types, which
instead receive their element
> type's OID), and the third is the |typmod| of the destination column,
if known (-1 will be passed if not).
https://www.postgresql.org/docs/current/sql-createtype.html

Inside the INPUT function it's not possible to identify which context
it's been called from. The only available arguments are the input text
as a C string, the type's OID and the typmod.

> I'm not averse to doing something here, because it's certainly a mess
> as mentioned by the comment right above your proposed patch. But this
> patch looks like "let's break half the universe for the benefit of the
> other half".
If the rest of the universe already knows what to do in case the third
argument is -1 or the known typmod, nothing should break.
> (And, given the shortage of prior complaints, that's
> being very generous about the proportion of data types that would
> benefit.)

Nobody complaining doesn't mean non-existance of the problem. It might
just mean they are all working around.

I have not revised many other extensions, but in postgis I can confirm
INPUT function in handles the typmod correctly when available
(lwgeom_inout.c lines 172 to 180).  This patch would not break postfix.
I can also confirm postgis is using the CAST workaround for the case
when typmod in the INPUT function is -1.  Postgis would not need such
workaround if typmod was passed correctly to the INPUT function. Postgis
is loosing efficiency because of this workaround.

I can look into other data type extensions if required to.

> I think the way to move forward here would be to invent an explicit
> datatype property that controls what to do.
Why not just allow the INPUT function to work as documented?
> I'm too tired to think
> through exactly what the definition of the property would be, but
> I suspect it'd have something to do with whether implicit and explicit
> coercion behaviors are supposed to differ.

INPUT function is not aware of coercion behaviors. It's just not working
as documented in https://www.postgresql.org/docs/current/sql-createtype.html

The proposed patch fixes INPUT function to work as documented.

>
> regards, tom lane
>
>
>

--
Sandino Araico Sánchez
http://sandino.net