On Fri, Feb 21, 2014 at 05:20:06PM -0500, Tom Lane wrote: > Noah Misch <n...@leadboat.com> writes: > > On Wed, Feb 19, 2014 at 08:22:13PM -0500, Tom Lane wrote: > >> 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. > > That's certainly a reasonable position to take concerning the changes for > outside-a-transaction behavior. However, I think there's a case to be > made for adding the additional pg_verify_mbstr() calls in the back > branches. We've been promising since around 8.3 that invalidly encoded > data can't get into a database, and it's disturbing to find that there > are leaks in that.
I had a dark corner of an app break from the 8.4-vintage change to make E'abc\000def'::text raise an error rather than truncate the string. The old behavior was clearly wrong, but I was still glad the change arrived in a major release; the truncation happened to be harmless for that app. Adding pg_verify_mbstr() calls creates a similar situation. Anything broken by the outside-a-transaction behavior change will be in C code. I'll expect between zero and one reports of breakage from that, so whether to back-patch that is more academic. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
