From mail at joeconway.com  Wed Jun 20 22:09:44 2007
From: mail at joeconway.com (Joe Conway)
Date: Wed, 20 Jun 2007 13:09:44 -0700
Subject: [Rd] clients and carriage returns
In-Reply-To: <Pine.LNX.4.64.0706201814350.28523@gannet.stats.ox.ac.uk>
References: <46795C8C.8080304@joeconway.com>
	<Pine.LNX.4.64.0706201814350.28523@gannet.stats.ox.ac.uk>
Message-ID: <46798988.60206@joeconway.com>

Prof Brian Ripley wrote:
> I think the question is how are you accessing the parser?  The only 
> public interface is R_ParseVector, and that works like parse(text=):

Yes, I'm using R_ParseVector. PL/R basically takes the function's text 
as stored in the Postgres system catalog table (prosrc field of 
pg_catalog.pg_proc), and feeds it to R_ParseVector more-or-less 
unchanged (currently).

> This does not happen when reading from files, as the connection 
> machinery converts line endings (or fgets does).  So I think the problem 
> may be in how you (or PostgreSQL) are getting text from files.

That makes sense. Many people use a database client such as PgAdmin III 
to create PL/R (and other) functions. PgAdmin adds standard Win32 EOLs 
to multiline CREATE FUNCTION statements, and Postgres dutifully stores 
them with the rest of the text in the catalog, exactly as received.

> The rules of R syntax are quite simple, e.g.
> 
>   Newlines have a function which is a combination of token separator and
>   expression terminator.  If an expression can terminate at the end of
>   the line the parser will assume it does so, otherwise the newline is
>   treated as whitespace.  Semicolons (@samp{;}) may be used to separate
>   elementary expressions on the same line.

I saw this paragraph, but it failed to register (through my thick skull) 
that Newline is quite literally \n. Thanks for pointing it out.

Best regards,

Joe



[Rd] clients and carriage returns
Joe Conway