Re: Bug in UTF8-Validation Code? - Mailing list pgsql-hackers

From Michael Paesold
Subject Re: Bug in UTF8-Validation Code?
Date
Msg-id 45F79DE1.1070700@gmx.at
Whole thread Raw
In response to Re: Bug in UTF8-Validation Code?  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Bug in UTF8-Validation Code?  (Peter Eisentraut <peter_e@gmx.net>)
Re: Bug in UTF8-Validation Code?  (Mario Weilguni <mweilguni@sime.com>)
List pgsql-hackers
Andrew Dunstan wrote:
> Albe Laurenz wrote:
>> A fix could be either that the server checks escape sequences for 
>> validity
>>   
> 
> This strikes me as essential. If the db has a certain encoding ISTM we 
> are promising that all the text data is valid for that encoding.
> 
> The question in my mind is how we help people to recover from the fact 
> that we haven't done that.

I would also say that it's a bug that escape sequences can get characters 
into the database that are not valid in the specified encoding. If you 
compare the encoding to table constraints, there is no way to simply 
"escape" a constraint check.

This seems to violate the principle of consistency in ACID. Additionally, 
if you include pg_dump into ACID, it also violates durability, since it 
cannot restore what it wrote itself.
Is there anything in the SQL spec that asks for such a behaviour? I guess not.

A DBA will usually not even learn about this issue until they are presented 
with a failing restore.

Best Regards,
Michael Paesold


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Log levels for checkpoint/bgwriter monitoring
Next
From: Michael Fuhr
Date:
Subject: Re: Bug in UTF8-Validation Code?