Re: invalidly encoded strings

Ühel kenal päeval, T, 2007-09-18 kell 08:08, kirjutas Andrew Dunstan:
>
> Tom Lane wrote:
> > Andrew Dunstan <andrew(at)dunslane(dot)net> 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