From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | digoal(at)126(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding |
Date: | 2014-02-13 20:49:08 |
Message-ID: | 20127.1392324548@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
digoal(at)126(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | john gale | 2014-02-14 00:48:43 | some postgres 2s SELECT queries are deadlocking forever in __sendto (libsystem_kernel.dylib) |
Previous Message | Bruce Momjian | 2014-02-13 20:39:20 | Re: BUG #8467: Slightly confusing pgcrypto example in docs |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-02-13 21:15:42 | Re: issue with gininsert under very high load |
Previous Message | Alvaro Herrera | 2014-02-13 20:44:13 | Re: truncating pg_multixact/members |