William ZHANG wrote:
It's safe, because you'll be dealing with prosrc inside the backend,
therefore using a backend-legal encoding, and those don't have any ASCII
aliasing problems (all bytes of an MB character must have high bit set).
The lower byte of some characters in BIG5, GBK, G
"Joe Conway" <[EMAIL PROTECTED]>
> Tom Lane wrote:
>> Joe Conway <[EMAIL PROTECTED]> writes:
>>> My first thought on fixing this issue was to simply replace all
>>> instances of '\r' in pg_proc.prosrc with '\n' prior to sending it to the
>>> R parser. As far as I know, any instances of '\r' embe
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
My first thought on fixing this issue was to simply replace all
instances of '\r' in pg_proc.prosrc with '\n' prior to sending it to the
R parser. As far as I know, any instances of '\r' embedded in a
syntactically valid R statement must b
Joe Conway wrote:
I finally was able PL/R to compile and run on Windows recently. This
has lead to people using a Windows based client (typically PgAdmin
III) to create PL/R functions. Immediately I started to receive
reports of failures that turned out to be due to the carriage return
(\r)
Joe Conway <[EMAIL PROTECTED]> writes:
> I finally was able PL/R to compile and run on Windows recently. This has
> lead to people using a Windows based client (typically PgAdmin III) to
> create PL/R functions. Immediately I started to receive reports of
> failures that turned out to be due to
I finally was able PL/R to compile and run on Windows recently. This has
lead to people using a Windows based client (typically PgAdmin III) to
create PL/R functions. Immediately I started to receive reports of
failures that turned out to be due to the carriage return (\r) used in
standard Win3
