What @Jack said.
Plus, to be precise, the cast in your
INSERT is "implicit" in a common sense:
insert into d values ( 42 );
But it's an assignment cast, not an implicit cast in Postgres terminology. That's an important distinction to make, implicit casts have far more applications. See:
Assignment or implicit casts only happen based on ...
castcontext = 'a' or
castcontext = 'i' respectively.
The complete list for your current installation:
SELECT casttarget::regtype AS target_type
, castsource::regtype AS source_type
WHERE castcontext IN ('i', 'a')
ORDER BY 1, 2;
2. Additional generic rules
It should be noted that
pg_cast does not represent every type
conversion that the system knows how to perform; only those that
cannot be deduced from some generic rule. For example, casting between
a domain and its base type is not explicitly represented in
Another important exception is that “automatic I/O conversion casts”,
those performed using a data type's own I/O functions to convert to or
text or other string types, are not explicitly represented in
Bold emphasis mine.
You could theoretically mess with entries in
pg_cast by changing
'e' ("explicit") - which can have far reaching consequences and is a bad idea unless you know exactly what you are doing - but not with automatic I/O conversion casts.
Quoting the manual about "Constants" once more:
There are three kinds of implicitly-typed constants in PostgreSQL:
strings, bit strings, and numbers. Constants can also be specified
with explicit types, which can enable more accurate representation and
more efficient handling by the system.
More details in that chapter.
unknown-type literals are strings and can be cast using the above mentioned “automatic I/O conversion casts”. But Postgres needs to determine the target type before figuring out an appropriate cast. In plain assignment, the target type is obvious. In other cases, determining the target type can be tricky. There are extensive bodies of rules in: