From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
Subject: | Re: PQescapeBytea is not multibyte aware |
Date: | 2002-04-05 16:32:35 |
Message-ID: | 24708.1018024355@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Joe Conway <mail(at)joeconway(dot)com> writes:
> But the error comes from pg_verifymbstr. Since bytea has no encoding
> (it's just an array of bytes afterall), why does pg_verifymbstr get
> applied at all to bytea data?
Because textin() is used for the initial conversion to an "unknown"
constant --- see make_const() in parse_node.c.
> pg_verifymbstr is called by textin, bpcharin, and varcharin. Would it
> help to rewrite this as:
> INSERT INTO t1(bytea_col) VALUES('characters produced by
> PQescapebytea'::bytea);
Probably that would cause the error to disappear, but it's hardly a
desirable answer.
I wonder whether this says that TEXT is not a good implementation of
type UNKNOWN. That choice was made on the assumption that TEXT would
faithfully preserve the contents of a C string ... but it seems that in
the multibyte world it ain't so. It would not be a huge amount of work
to write a couple more I/O routines and give UNKNOWN its own I/O
behavior.
OTOH, I was surprised to read your message because I had assumed the
damage was being done much further upstream, viz during collection of
the query string by pq_getstr(). Do we need to think twice about that
processing, as well?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fernando Nasser | 2002-04-05 16:39:55 | Re: What's the CURRENT schema ? |
Previous Message | Josh Berkus | 2002-04-05 16:30:08 | Re: 16 parameter limit |
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2002-04-05 17:21:42 | Re: PQescapeBytea is not multibyte aware |
Previous Message | Josh Berkus | 2002-04-05 16:30:08 | Re: 16 parameter limit |