Re: PL/Perl embedding string common elements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-patches(at)postgresql(dot)org
Subject: Re: PL/Perl embedding string common elements
Date: 2005-08-21 03:11:33
Message-ID: 19384.1124593893@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2005-08-21 14:26:48 Re: PostgreSQL 8.0.3 and Ipv6
Previous Message Andrew Dunstan 2005-08-21 02:49:32 Re: PL/Perl embedding string common elements