On 2024/06/27, 18:13, "David G. Johnston" <mailto:david.g.johnston@gmail.com> wrote:
> A cast between two types is going to accept a concrete instance of the input type, in memory, as its argument and
thenproduces a concrete instance of the output type, in memory, as output. If the input data is serialized the
constructorfor the input type will handle deserialization.
I confess to some uncertainty whether the PostgreSQL specific x::y notation and the standards based CAST(x AS y) would
bothbe addressed by creating a cast. What you’re saying means both forms engage the same code and defining a cast would
coverthe :: syntax as well. Thanks for that.
If my understanding is accurate, it means that even when both values are of MyType the CAST function would still be
invokedso the type logic can determine how to handle (or reject) the cast. Cast would (obviously) require the target
typemodifiers as well, and the good news is that it’s already there as the second parameter of the function. So that’s
theother function that receives the type modifier that I was missing. It’s starting to make plenty sense.
To summarise:
- The type modifiers, encoded by the TYPMOD_IN function are passed directly as parameters to:-
- the type's input function (parameter 3), and
- any "with function" cast where the target type has type modifiers.
- Regardless of the syntax used to invoke the cast, the same function will be called.
- Depending on what casts are defined, converting from the external string format to a value of MyType will be handled
eitherby the input function or a cast function. By default (without any casts) only values recognised by input can be
convertedto MyType values.
-- Thanks for your time – Marthin Laubscher