Tom Lane wrote:
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.
Not sure what you mean by this. Perl strict mode in fact does very
little checking on function calls - the existence and visibility of the
function is checked at call time, not compile time. This can be a bit
annoying, especially if you're switching backwards and forwards between
perl and some language that is less, er, forgiving, but it's essential
to the way perl works.
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 ...
It might well say that in the TODO, but actually doing it is another
matter entirely. I spent a long time looking at this. Quite apart from
issues of name mangling to get plperl and SQL names aligned, there is
the fact that, with the exception of CREATE OR REPLACE FUNCTION, we
only compile a function when it is first called by SQL. So we'd need to
ensure that every known function was compiled in every backend for which
it is visible in case we need to call it directly. There might be some
way that I can't see to do it - I'm meeting a few perl gurus in a few
weeks and I'll ask if I get the chance.
Also, we'd need to work out a way for custom GUCs to work on startup
only - I know it broke for me.
So let's just design for what we have now ;-)
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
