Andrew Dunstan <andrew@dunslane.net> writes:
> What's bothering me here though is that in the two argument forms, if
> the first argument is text the second argument is the destination
> encoding, but if the first argument is a bytea the second argument is
> the source encoding. That strikes me as likely to be quite confusing,
> and we might alleviate that with something like:
> text convert_from(bytea, name)
> bytea convert_to(text, name)
In a green field this would be fine, but what will you do with the
existing 2-argument form of convert()?
[ pokes around... ] Actually, on looking into it, it seems the
2-argument form of convert() is there because somebody thought it
would be a suitable approximation to SQL99's <form-of-use conversion>,
which in reality I fear means something different entirely. I might
not be grasping what the spec is trying to say, but I *think* that
what they intend is that the argument of CONVERT(x USING encoding)
has to be a client-side variable in embedded SQL, and that the intent
is that x is in the specified encoding and it's brought into the
DB encoding by the function. Or maybe I'm all wrong.
Anyway, on the strength of that, these functions are definitely
best named to stay away from the spec syntax, so +1 for your
proposal above.
regards, tom lane
