Re: syntax error in plperl wrapper for Perl regex replace.

Tom,

You are right, it is a Perl's fault, not Postgre's.

You are right also with assumption, that the "s" command of Perl does not accept variable
in every of it's part. I have narrowed down the problem (btw, I could not find anything
about it is Perl docs) to the options part, ie. after last slash. Perl only accepts literals
there, not a variable of any kind. So these options must be hardcoded, not a dynamic value
constructed at runtime.

This compiles:
s/$_[1]/$_[2]/ig;

But even then, the command does not work as expected, as it does not interpret the
backreferences in a replacement string passed to it. It uses it literally. For example,
one would expect that the following call will return 'Praha':

select perl_regexp_replace ('PRAHA', '^(.)(.*)$', '$1\L$2');

But it returns:
$1\L$2

Well, Perl is praised for it's capabilities at the field of text processing, but this
experience disappointed me a little bit. Never mind, I will solve the things different way.

Thank you all for your inputs.

Regards, Roman Golis.

####################################
On Thu, 23 Aug 2018 22:17:10 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "io.sys" <io(dot)sys(at)post(dot)cz> writes:
> > I just tried to use function parameters $_[1], $_[2], $_[3] instead fixed strings.
> > However, it is rejected by postgre as syntax error.
>
> That's not a Postgres problem, it's a Perl problem. I'm no Perl
> expert, but I think if you study the Perl docs carefully you will
> find there are restrictions on what sorts of variable references
> can be interpolated into a regexp ... and a subscripted reference
> probably doesn't qualify.
>
> regards, tom lane