Bruce Momjian wrote:
> I am hoping for a patch for this for 7.3. Added to open items:
>
> Fix bytea to not encode input string
>
I said:
> Here's the remaining issue that I remembered; see:
> http://archives.postgresql.org/pgsql-hackers/2002-04/msg00256.php
>
> The gist of this is that w
I am hoping for a patch for this for 7.3. Added to open items:
Fix bytea to not encode input string
---
Joe Conway wrote:
> Joe Conway wrote:
> > Bruce Momjian wrote:
> >
> >> Does this mean we don't have to esa
Joe Conway wrote:
> Bruce Momjian wrote:
>
>> Does this mean we don't have to esacpe >0x7f when inputting bytea
>> anymore?
>
>
> I seem to remember that bytea data was run through the multibute code
> for some reason, and I don't recall seeing that changed. ISTM that we
> shouldn't force byt
Bruce Momjian wrote:
> Does this mean we don't have to esacpe >0x7f when inputting bytea
> anymore?
I seem to remember that bytea data was run through the multibute code
for some reason, and I don't recall seeing that changed. ISTM that we
shouldn't force bytea thought multibyte functions at al
Joe Conway wrote:
> Tom Lane wrote:
> > Ah. So the issue is that ANALYZE tries to do textin(byteaout(...))
> > in order to produce a textual representation of the most common value
> > in the BYTEA column, and apparently textin feels that the string
> > generated by byteaout is not legal text. W
Tom Lane wrote:
> Ah. So the issue is that ANALYZE tries to do textin(byteaout(...))
> in order to produce a textual representation of the most common value
> in the BYTEA column, and apparently textin feels that the string
> generated by byteaout is not legal text. While Joe says that the
> pro
Joe Conway <[EMAIL PROTECTED]> writes:
> (gdb) bt
> #0 pg_verifymbstr (mbstr=0x837a698 "42", len=2) at wchar.c:541
> #1 0x08149c26 in textin (fcinfo=0xbfffeca0) at varlena.c:191
> #2 0x08160579 in DirectFunctionCall1 (func=0x8149c00 ,
> arg1=137864856) at fmgr.c:657
> #3 0x080bbffa in update_
Anders Hammarquist wrote:
>>[EMAIL PROTECTED] writes:
>>
>>>If a byte string that is not valid unicode is inserted into a bytea
>>>column, analyze will fail unless the data was tagged as bytea in the
>>>insert.
>>
>>Your example produces no failure for me. You'd better be more specific
>>about wh
> [EMAIL PROTECTED] writes:
> > If a byte string that is not valid unicode is inserted into a bytea
> > column, analyze will fail unless the data was tagged as bytea in the
> > insert.
>
> Your example produces no failure for me. You'd better be more specific
> about which PG version you're runn
[EMAIL PROTECTED] writes:
> If a byte string that is not valid unicode is inserted into a bytea
> column, analyze will fail unless the data was tagged as bytea in the
> insert.
Your example produces no failure for me. You'd better be more specific
about which PG version you're running, on what p
Anders Hammarquist ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Interactions between bytea and character encoding when doing analyze
Long Description
If a byte string that is not valid unicode is inserted into a bytea
column
11 matches
Mail list logo
