Re: BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding - Mailing list pgsql-hackers

From Noah Misch
Subject Re: BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding
Date
Msg-id 20140220043940.GA3064539@tornado.leadboat.com
Whole thread Raw
In response to Re: [BUGS] BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Priority table or Cache table
Next
From: Haribabu Kommi
Date:
Subject: Re: Priority table or Cache table