[postgis-users] New day, new problem - now with pl/r

[Paragon Corporation]

Darrel,
It could also have to do with  a particular package you have in R installed.  

I actually misspoke a bit.  I forgot that the load_r_typenames() function must be called first - which explains my error  (so I have no error :) )  so full needs to be:

SELECT load_r_typenames(); -- should just return OK.

Followed by:
SELECT * FROM r_typenames() limit 10;


If it's hanging in the load_r_typenames() call, and given it works for me (and fails on both your setups, I would seriously suspect an R package you have loaded is tripping PL/R)
Probably still worthwhile to report to PL/R list and Joe could provide tips on narrowing down the issue.


Do other queries work okay?  Like this:  

SELECT plr_array_accum('{23,35}', 42);


Thanks,
Regina



From: postgis-users [mailto:postgis-users-bounces at lists.osgeo.org] On Behalf Of Darrel Maddy
Sent: Sunday, November 08, 2015 3:12 PM
To: PostGIS Users Discussion <postgis-users at lists.osgeo.org>
Subject: Re: [postgis-users] New day, new problem - now with pl/r

OK everything checks out in the command window. Path is set correctly, as is R_HOME (as a system variable). I guess this was already evident in the first query which retrieves these correctly from plr_environ();

I experimented by trying to run the plr sql scripts but they did not run because the functions were already defined. I guess this means the plr extension installed correctly. R is working just fine from the directory pointed to by R_HOME.  I tried your new variant but that did not work either in PgAdmin.

As this problem exists on both my laptop and my workstation (both run windows 10 and the same versions of postgresql and postgis) I am now at a loss. This is a pity as I use R for most of my data analysis and visualisation and it would have been nice to do this in one step. Looks like I will have to output to file and then retrieve things directly in R. ☹

Many thanks for your help and suggestions. 

Darrel