Re: pg_do_encoding_conversion glitch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_do_encoding_conversion glitch
Date
Msg-id 3476.1226324303@sss.pgh.pa.us
Whole thread Raw
In response to pg_do_encoding_conversion glitch  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: pg_do_encoding_conversion glitch  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> I have a question about the result contract of pg_do_encoding_conversion().

It's poorly designed :-(

As near as I can tell, all uses of the function either pass a
null-terminated string or special-case the result == src case in such a
way that it doesn't matter.  However it's certainly not obvious that you
have to do that.

The calls in contrib/sslinfo might be broken --- not sure how much
that module has been tested.

Do you have a proposal for a different API, or do you just want to
improve the comment for the function?  Bear in mind that a lot of the
callers do know the string length, and so we shouldn't impose an
unnecessary strlen() operation on those cases.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: WIP: Page space reservation (pgupgrade)
Next
From: "Hitoshi Harada"
Date:
Subject: Re: Windowing Function Patch Review -> Standard Conformance