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
