Re: [HACKERS] a common place for pl/perlu modules

[Alexey Klyukin]

On Feb 11, 2010, at 7:07 PM, Andrew Dunstan wrote:

> 
> 
> Alexey Klyukin wrote:
>> On Feb 11, 2010, at 6:24 PM, Andrew Dunstan wrote:
>> 
>>  
>>> Alexey Klyukin wrote:
>>>
 Hello,
 
 When developing pl/perlu functions common definitions and methods are 
 often stored in external .pm modules. During deployment the modules should 
 be installed somewhere in @INC to be reachable by the perl interpreter. 
 However, installing the modules to a location outside of the PG 
 installation makes it hard to have a consistent environment when running 
 multiple PG versions on the same host. What do you think about defining a 
 canonical place for pl/perlu .pm modules (i.e. PKGLIBDIR) and adding this 
 location to @INC during the interpreter initialization ? Another idea is 
 to allow a user to specify such location by adding a new custom GUC 
 variable.
 
 
   
>>> Why won't setting this in the new on_perl_init setting work? It's even 
>>> included in to documented examples using the standard lib module: 
>>> 
>>>
>> 
>> The lack of support for SPI functions makes this hardly an adequate 
>> solution. I do have both modules and SPI calls in several pl/perlu functions.
>> 
>>  
> 
> 
> That has nothing to do with what you asked about, namely setting the include 
> path. You can set the include path in on_perl_init with "use lib" and then 
> "use" your modules in your plperlu functions, at which point SPI will be 
> available.

Ah, it seems I misinterpreted the documentation. This is much better, but still 
it requires setting the path explicitly. 
What about having a default location for the modules that is automatically 
added to @INC and is recommended in the documentation as a place to put .pm 
files  ?

--
Alexey Klyukin  http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] a common place for pl/perlu modules

[Andrew Dunstan]

Alexey Klyukin wrote:

On Feb 11, 2010, at 6:24 PM, Andrew Dunstan wrote:

  

Alexey Klyukin wrote:


Hello,

When developing pl/perlu functions common definitions and methods are often 
stored in external .pm modules. During deployment the modules should be 
installed somewhere in @INC to be reachable by the perl interpreter. However, 
installing the modules to a location outside of the PG installation makes it 
hard to have a consistent environment when running multiple PG versions on the 
same host. What do you think about defining a canonical place for pl/perlu .pm 
modules (i.e. PKGLIBDIR) and adding this location to @INC during the 
interpreter initialization ? Another idea is to allow a user to specify such 
location by adding a new custom GUC variable.


 
  

Why won't setting this in the new on_perl_init setting work? It's even included in to 
documented examples using the standard lib module: 




The lack of support for SPI functions makes this hardly an adequate solution. I 
do have both modules and SPI calls in several pl/perlu functions.

  



That has nothing to do with what you asked about, namely setting the 
include path. You can set the include path in on_perl_init with "use 
lib" and then "use" your modules in your plperlu functions, at which 
point SPI will be available.


cheers

andrew



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] a common place for pl/perlu modules

[Alexey Klyukin]

On Feb 11, 2010, at 6:24 PM, Andrew Dunstan wrote:

> 
> 
> Alexey Klyukin wrote:
>> Hello,
>> 
>> When developing pl/perlu functions common definitions and methods are often 
>> stored in external .pm modules. During deployment the modules should be 
>> installed somewhere in @INC to be reachable by the perl interpreter. 
>> However, installing the modules to a location outside of the PG installation 
>> makes it hard to have a consistent environment when running multiple PG 
>> versions on the same host. What do you think about defining a canonical 
>> place for pl/perlu .pm modules (i.e. PKGLIBDIR) and adding this location to 
>> @INC during the interpreter initialization ? Another idea is to allow a user 
>> to specify such location by adding a new custom GUC variable.
>> 
>> 
>>  
> 
> Why won't setting this in the new on_perl_init setting work? It's even 
> included in to documented examples using the standard lib module: 
> 

The lack of support for SPI functions makes this hardly an adequate solution. I 
do have both modules and SPI calls in several pl/perlu functions.


--
Alexey Klyukin  http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] a common place for pl/perlu modules

[Andrew Dunstan]

Alexey Klyukin wrote:

Hello,

When developing pl/perlu functions common definitions and methods are often 
stored in external .pm modules. During deployment the modules should be 
installed somewhere in @INC to be reachable by the perl interpreter. However, 
installing the modules to a location outside of the PG installation makes it 
hard to have a consistent environment when running multiple PG versions on the 
same host. What do you think about defining a canonical place for pl/perlu .pm 
modules (i.e. PKGLIBDIR) and adding this location to @INC during the 
interpreter initialization ? Another idea is to allow a user to specify such 
location by adding a new custom GUC variable.


  


Why won't setting this in the new on_perl_init setting work? It's even 
included in to documented examples using the standard lib module: 



cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] a common place for pl/perlu modules

[Alexey Klyukin]

Hello,

When developing pl/perlu functions common definitions and methods are often 
stored in external .pm modules. During deployment the modules should be 
installed somewhere in @INC to be reachable by the perl interpreter. However, 
installing the modules to a location outside of the PG installation makes it 
hard to have a consistent environment when running multiple PG versions on the 
same host. What do you think about defining a canonical place for pl/perlu .pm 
modules (i.e. PKGLIBDIR) and adding this location to @INC during the 
interpreter initialization ? Another idea is to allow a user to specify such 
location by adding a new custom GUC variable.

--
Alexey Klyukin  http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers