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.



---------------------------(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

Reply via email to