Awhile back I wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> 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

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to