Awhile back I wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> FWIW, is the attached patch about what you had in mind? (It probably only
>> covers "normal" types at the moment.)
> Hm, I hadn't realized that it would take as little work as that ...
> I have an itchy feeling that you missed something but I'm not sure
> what.
On closer inspection, my gut feeling was right: this patch doesn't work,
because it assumes that I/O functions have the same calling conventions
as cast functions, which they don't --- the semantics for second and
third arguments, if used, are different.
We could tweak build_coercion_expression() to generate the correct
arguments, but there are more problems downstream, eg in
exprIsLengthCoercion() which will misinterpret the arguments in such
a node. So I'm inclined to think that we really need a specialized
expression node type, perhaps "CoerceViaIO". This might have some
usefulness in plpgsql too, if it could piggyback on that rather than
doing its own ad-hoc conversions.
An alternative, which would be less pretty but also less work, is to
implement the cast this way only for types with single-argument input
functions. Those that require extra args would still have to have
explicit pg_cast entries. The main problem with this is we can't
support varchar on the same basis as text, because its input function
wants extra arguments.
BTW, I note that uuid has snuck in with assignment casts to and from
text. Is this really what we want if we're tightening up everything
else?
regards, tom lane
