--KuLpqunXa7jZSBt+
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

I hit the following bug:

this is with a 7.3.4 database server (and psql client)
PGCLIENTENCODING=3D"UTF-8"
and a utf-8 encoded database,

pensieve=3D> create table a(raw bytea);
CREATE TABLE
pensieve=3D> insert into a values('\770\711\056'::bytea);
INSERT 1112630 1
pensieve=3D> vacuum analyze a;
VACUUM
pensieve=3D> insert into a values('\770\711\056'::bytea);
INSERT 1112631 1
pensieve=3D> vacuum analyze a;
ERROR: Invalid UNICODE character sequence found (0xf8c92e)

I think bytea should accept ANY value and vaccuum analyze must
not complain about this.

Is this new to you?

Regards,


Michael


--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Michael Radziej SuSE Linux AG phone +49-911-74053-0
IT Deutschherrenstr. 15-19 fax +49-911-3206727
(vormals "interne EDV") 90429 N=FCrnberg, Germany web http://www.sus=
e.de
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Heute schon ge=E4ndert? -- simply cha=
nge

--KuLpqunXa7jZSBt+
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/eGLJHqfklhuMsrcRAoryAJkBHiuDbmwh7+c61wk24jZw4lG6ag Cgg3Qd
R0Dbq7XtxQ83WLL6HHskHDw=
=syiG
-----END PGP SIGNATURE-----

--KuLpqunXa7jZSBt+--

Michael Radziej <mir (AT) suse (DOT) de> writes:
This is fixed as of 7.4, I think (at least your example case doesn't
fail for me). 7.3 was a bit sloppy about how it treated entries in
pg_statistic ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly