I wrote: > I looked through all the callers of pg_do_encoding_conversion(), and > AFAICS this change is a good idea. There are a whole bunch of places > that use pg_do_encoding_conversion() to convert from the database encoding > to encoding X (most usually UTF8), and right now if you do that in a > SQL_ASCII database you have no assurance whatever that what is produced > is actually valid in encoding X. I think we need to close that loophole.
BTW, a second look confirms that all but one or two of the callers of pg_do_encoding_conversion() are in fact converting either to or from the database encoding. That probably means they ought to be using pg_any_to_server or pg_server_to_any instead, so that they can take advantage of the pre-cached default conversion in the not-unlikely situation that the other encoding is the current client_encoding. This would imply that we ought to put a validate-if-source-is-SQL_ASCII step into pg_server_to_any() as well, since that function currently short-circuits calling pg_do_encoding_conversion() in that case. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers