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@sss.pgh.pa.us> wrote:
> "io.sys" <io.sys@post.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
