> Joe Conway <[EMAIL PROTECTED]> writes:
> > No objection here, but can we wrap the change in #ifdef MULTIBYTE so
> > there's no effect for people who don't use MULTIBYTE?
>
> That opens up the standard set of issues about "what if your server is
> MULTIBYTE but your libpq is not?" It seems ris
Joe Conway <[EMAIL PROTECTED]> writes:
> No objection here, but can we wrap the change in #ifdef MULTIBYTE so
> there's no effect for people who don't use MULTIBYTE?
That opens up the standard set of issues about "what if your server is
MULTIBYTE but your libpq is not?" It seems risky to me.
Tatsuo Ishii wrote:
> BTW, for the 7.2.x tree we need a solution with lesser impact.
> For this purpose, I would like to change PQescapeBytea as I stated in
> the previous mail. Objection?
> --
> Tatsuo Ishii
No objection here, but can we wrap the change in #ifdef MULTIBYTE so
there's no effect
> Hmm, so essentially we'd have to convert all codes >= 0x80 to prevent
> them from being mistaken for parts of multibyte sequences?
Yes.
> Ugh, but
> you're probably right. It looks to me like byteaout does the reverse
> already.
As for the new UNKNOWN data type, that seems a good thing for
m
Joe Conway <[EMAIL PROTECTED]> writes:
> But still, doesn't that mean roughly twice as much memory usage for each
> copy of the string? And I seem to remember Jan saying that each datum
> winds up having 4 copies in memory. It ends up impacting the practical
> length limit for a bytea value.
Well
Tom Lane wrote:
>> Yuck! At that point you're no better off than converting to hex
>> (and worse off than converting to base64) for storage.
>
>
> No; the *storage* is still compact, it's just the I/O representation
> that's not.
Yeah, I realized that after I pushed send ;)
But still, does
Joe Conway <[EMAIL PROTECTED]> writes:
>> This scenario is probably why Tatsuo wants PQescapeBytea to octalize
>> everything with the high bit set; I'm not sure there's any lesser way
> Yuck! At that point you're no better off than converting to hex (and
> worse off than converting to base64) fo
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>
>>I think you're correct that in a client/database encoding mismatch
>>scenario, there would be bigger problems. Thoughts on this?
>
>
> This scenario is probably why Tatsuo wants PQescapeBytea to octalize
> everything with the high bi
Joe Conway <[EMAIL PROTECTED]> writes:
> I think you're correct that in a client/database encoding mismatch
> scenario, there would be bigger problems. Thoughts on this?
This scenario is probably why Tatsuo wants PQescapeBytea to octalize
everything with the high bit set; I'm not sure there's an
Tom Lane wrote:
>
> 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?
>
I just looked in pq_getstr() I see:
Joe Conway <[EMAIL PROTECTED]> writes:
> I could take a look at this. Any guidance other than "faithfully
> preserving the contents of a C string"?
Take textin/textout, remove multibyte awareness? Actually the hard
part is to figure out which of the existing hardwired calls of textin
and textou
Tom Lane wrote:
>>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 choic
Joe Conway <[EMAIL PROTECTED]> 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 --- se
Tom Lane wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>
>>PQescapebytea() is not multibyte aware and will produce bad multibyte
>>character sequences. Example:
>>I think 0x89 should be converted to '\\211' since 0x89 of 0x8950 is
>>considered as "non printable characters".
>
>
> Hmm, so es
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> PQescapebytea() is not multibyte aware and will produce bad multibyte
> character sequences. Example:
> I think 0x89 should be converted to '\\211' since 0x89 of 0x8950 is
> considered as "non printable characters".
Hmm, so essentially we'd have to conve
PQescapebytea() is not multibyte aware and will produce bad multibyte
character sequences. Example:
INSERT INTO t1(bytea_col) VALUES('characters produced by
PQescapebytea');
ERROR: Invalid EUC_JP character sequence found (0x8950)
I think 0x89 should be converted to '\\211' since 0x89 of 0x8950
16 matches
Mail list logo
