Re: PL/Perl embedding string common elements

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PL/Perl embedding string common elements
Дата
Msg-id 19384.1124593893@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: PL/Perl embedding string common elements  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: PL/Perl embedding string common elements  (Andrew Dunstan <andrew@dunslane.net>)
Re: PL/Perl embedding string common elements  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: PL/Perl embedding string common elements
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: PL/Perl embedding string common elements