Andrew Dunstan <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster