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 ;-)



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to