Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group