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

Re: PL/Perl embedding string common elements

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 14:39:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches

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



In response to

pgsql-patches by date

Next:From: Tom LaneDate: 2005-08-21 15:08:34
Subject: Re: PostgreSQL 8.0.3 and Ipv6
Previous:From: Andrew DunstanDate: 2005-08-21 14:26:48
Subject: Re: PostgreSQL 8.0.3 and Ipv6

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