PLR Master + pg12beta2 + Mac OS X Mojave

[JamesInform]

Hi Joseph,

I compiled PLR (Master) successfully on MacOs Mojave.
When I create the extension and try to create a function from the manual, I get the following error:

test=# create extension plr;
CREATE EXTENSION
test=# CREATE OR REPLACE FUNCTION r_max (integer, integer) RETURNS integer AS '
test'# if (arg1 > arg2)
test'# return(arg1)
test'# else
test'# return(arg2)
test'# ' LANGUAGE 'plr' STRICT;
psql: ERROR: R interpreter parse error
DETAIL: R parse error caught in "
if (arg1 > arg2)
return(arg1)
else
return(arg2)
".
test=#

But when I put the "else" directly after "return(arg1)" then everything is fine:

test=# CREATE OR REPLACE FUNCTION r_max (integer, integer) RETURNS integer AS '
test'# if (arg1 > arg2)
test'# return(arg1) else
test'# return(arg2)
test'# ' LANGUAGE 'plr' STRICT;
CREATE FUNCTION
test=#

Could it be that PLR extension has problems with line feeds?

On PostgreSQL 11 with PLR 8.4 everything works fine as expected!

James

[davecramer]

@mlt I wonder if the PR that added the syntax checking broke this ?

[mlt]

Somehow I feel like curly braces are missing. Does the second example run alright?

Line endings are sanitized in both cases: on validation and on running. I tried to bring this up on R-dev mailing list as in why for a parser not to ignore CRs... But those guys are harsh :(

[JamesInform]

Yes, the second example run alright!

Curly braces doesn't fix it. The error seems to occur every time the "ELSE" is on a new line.

Btw. the function example is taken from the official PLR documentation:

http://www.joeconway.com/plr/doc/plr-funcs.html

[mlt]

I confirm the issue with PG 11 on Windows. When validating, I try to parse just function body without function(args) {...} stuff. Hence, I presume, R tries to parse each line into its own SEXP and somehow it is not good on top level. This seems to be consistent with R REPL

> if (2)
+ 3
[1] 3
> else 4
Error: unexpected 'else' in "else"

My plan is to wrap function body in {...} for validation (basic syntax check) purposes only. I'm not sure there is any reason to generate accurate function definition at this point.

For quick workaround, one can create language without validator.

CREATE LANGUAGE plr
HANDLER plr_call_handler
INLINE plr_inline_handler;
-- VALIDATOR plr_validator;

I'll provide the patch.