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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Priority table or Cache table
Следующее
От: Haribabu Kommi
Дата:
Сообщение: Re: Priority table or Cache table