Re: PL/Perl embedding string common elements - Mailing list pgsql-patches

From Tom Lane
Subject Re: PL/Perl embedding string common elements
Date
Msg-id 19384.1124593893@sss.pgh.pa.us
Whole thread Raw
In response to Re: PL/Perl embedding string common elements  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: PL/Perl embedding string common elements  (Andrew Dunstan <andrew@dunslane.net>)
Re: PL/Perl embedding string common elements  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-patches
Andrew Dunstan <andrew@dunslane.net> writes:
> Do you expect turning it on to affect only future compilations? Or
> should we recompile every function already compiled in the present
> backend? I can see arguments either way.

Yeah, me too.  I would definitely expect a change in the variable
(in either direction) to be respected in subsequent function
compilations.  I'm less excited about redoing previous compilations;
a case could be made for doing so, but I won't insist on it.
I think the main case where use_strict is interesting is in development,
where you're repeatedly CREATE OR REPLACE'ing the function and retesting
it, so you're going to be doing new compilations anyway.

Looking ahead to the future a bit, is there any reason to expect that
use_strict would have cross-function effects?  In a normal Perl script
I suppose it does add some cross-function checking.  Right now, with
plperl functions all mutually anonymous, there are no interactions to
be strict about --- but it says in the todo list that that's something
to fix someday.  When that happens, would it actually be correct or
even essential to force use_strict to have just one value throughout a
backend's lifespan?  If so, the existing code isn't so unreasonable,
but we need to fix the docs ...

            regards, tom lane

pgsql-patches by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: PL/Perl embedding string common elements
Next
From: Andrew Dunstan
Date:
Subject: Re: PL/Perl embedding string common elements