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

From Tom Lane
Subject Re: [BUGS] BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding
Date
Msg-id 20127.1392324548@sss.pgh.pa.us
Whole thread Raw
Responses Re: [BUGS] BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding  (digoal <digoal@126.com>)
Re: [BUGS] BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
digoal@126.com writes:
> select t, t::bytea from convert_from('\xeec1', 'sql_ascii') as g(t);
> [ fails to check that string is valid in database encoding ]

Hm, yeah.  Normal input to the database goes through pg_any_to_server(),
which will apply a validation step if the source encoding is SQL_ASCII
and the destination encoding is something else.  However, pg_convert and
some other places call pg_do_encoding_conversion() directly, and that
function will just quietly do nothing if either encoding is SQL_ASCII.

The minimum-refactoring solution to this would be to tweak
pg_do_encoding_conversion() so that if the src_encoding is SQL_ASCII but
the dest_encoding isn't, it does pg_verify_mbstr() rather than nothing.

I'm not sure if this would break anything we need to have work,
though.  Thoughts?  Do we want to back-patch such a change?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: truncating pg_multixact/members
Next
From: Tom Lane
Date:
Subject: Re: issue with gininsert under very high load