Ühel kenal päeval, T, 2007-09-18 kell 08:08, kirjutas Andrew Dunstan: > > 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)
how is this fundamentally different from encode/decode functions we have now ? > 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings