Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
What I think we'd need to have a complete solution is
convert(text, name) returns bytea
-- convert from DB encoding to arbitrary encoding
convert(bytea, name, name) returns bytea
-- convert between any two encodings
convert(bytea, name) returns text
-- convert from arbitrary encoding to DB encoding
The second and third would need to do a verify step before
converting, of course.
I'm wondering if we should give them disambiguating names, rather than
call them all convert.
No. We have a function overloading system, we should use it.
In general I agree with you.
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)
But if I'm the only one bothered by it I won't worry.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
