Re: BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding
От | Noah Misch |
---|---|
Тема | Re: BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding |
Дата | |
Msg-id | 20140220043940.GA3064539@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding
|
Список | pgsql-hackers |
On Wed, Feb 19, 2014 at 08:22:13PM -0500, Tom Lane wrote: > The more I looked into mbutils.c, the less happy I got. The attached > proposed patch takes care of the missing-verification hole in > pg_do_encoding_conversion() and pg_server_to_any(), and also gets rid > of what I believe to be obsolete provisions in pg_do_encoding_conversion > to "work" if called outside a transaction --- if you consider it working > to completely fail to honor its API contract. That should no longer be > necessary now that we perform client<->server encoding conversions via > perform_default_encoding_conversion rather than here. I like these changes. In particular, coping with the absence of a conversion function by calling ereport(LOG) and returning the source string was wrong for nearly every caller, but you'd need to try an encoding like MULE_INTERNAL to notice the problem. Good riddance. > How much of this is back-patch material, do you think? None of it. While many of the failures to validate against a character encoding are clear bugs, applications hum along in spite of such bugs and break when we tighten the checks. I don't see a concern to override that here. Folks who want the tighter checking have some workarounds available. Thanks, nm -- Noah Misch EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: