-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I found something that I believe to be a bug in postgresql handling of
the chr function. This function takes an ascii code and returns the
character.
Now it seems that a value greater than 191 seems to cause trouble with a
backend instance of p
Wiktor Wodecki <[EMAIL PROTECTED]> writes:
> I found something that I believe to be a bug in postgresql handling of
> the chr function. This function takes an ascii code and returns the
> character.
What database encoding are you testing in?
regards, tom lane
Tom Lane wrote:
> Wiktor Wodecki <[EMAIL PROTECTED]> writes:
>> I found something that I believe to be a bug in postgresql handling of
>> the chr function. This function takes an ascii code and returns the
>> character.
>
> What database encoding are you testing in?
FWIW, I can reproduce this wit
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> FWIW, I can reproduce this with UTF-8, on REL_8_2_STABLE.
I can reproduce an out-of-memory condition (basically, replace() is
going into an infinite loop because of the invalid input) but I'm
not seeing any crash.
regards, t
Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> FWIW, I can reproduce this with UTF-8, on REL_8_2_STABLE.
>
> I can reproduce an out-of-memory condition (basically, replace() is
> going into an infinite loop because of the invalid input) but I'm
> not seeing any crash.
replace
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I can reproduce an out-of-memory condition (basically, replace() is
>> going into an infinite loop because of the invalid input) but I'm
>> not seeing any crash.
> replace_text reads past the end of source string, byte by byte (or
Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> I can reproduce an out-of-memory condition (basically, replace() is
>>> going into an infinite loop because of the invalid input) but I'm
>>> not seeing any crash.
>
>> replace_text reads past the end of source
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I agree we should do the above changes for the sake of robustness, but
> isn't the real problem here that chr function can return invalid byte
> sequences? That was actually discussed a while back (starting at
> http://archives.postgresql.org/pgsql-h