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 else? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate