Обсуждение: a common place for pl/perlu modules
Hello, When developing pl/perlu functions common definitions and methods are often stored in external .pm modules. During deploymentthe modules should be installed somewhere in @INC to be reachable by the perl interpreter. However, installingthe modules to a location outside of the PG installation makes it hard to have a consistent environment when runningmultiple 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 allowa user to specify such location by adding a new custom GUC variable. -- Alexey Klyukin http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc
Alexey Klyukin wrote: > Hello, > > When developing pl/perlu functions common definitions and methods are often stored in external .pm modules. During deploymentthe modules should be installed somewhere in @INC to be reachable by the perl interpreter. However, installingthe modules to a location outside of the PG installation makes it hard to have a consistent environment when runningmultiple 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 allowa 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: <http://developer.postgresql.org/pgdocs/postgres/plperl-under-the-hood.html#PLPERL-CONFIG> cheers andrew
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 deploymentthe modules should be installed somewhere in @INC to be reachable by the perl interpreter. However, installingthe modules to a location outside of the PG installation makes it hard to have a consistent environment when runningmultiple 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 allowa 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 standardlib module: <http://developer.postgresql.org/pgdocs/postgres/plperl-under-the-hood.html#PLPERL-CONFIG> The lack of support for SPI functions makes this hardly an adequate solution. I do have both modules and SPI calls in severalpl/perlu functions. -- Alexey Klyukin http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc
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 deploymentthe modules should be installed somewhere in @INC to be reachable by the perl interpreter. However, installingthe modules to a location outside of the PG installation makes it hard to have a consistent environment when runningmultiple 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 allowa 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 standardlib module: <http://developer.postgresql.org/pgdocs/postgres/plperl-under-the-hood.html#PLPERL-CONFIG> >> > > The lack of support for SPI functions makes this hardly an adequate solution. I do have both modules and SPI calls in severalpl/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
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 deploymentthe modules should be installed somewhere in @INC to be reachable by the perl interpreter. However, installingthe modules to a location outside of the PG installation makes it hard to have a consistent environment when runningmultiple 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 allowa 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 standardlib module: <http://developer.postgresql.org/pgdocs/postgres/plperl-under-the-hood.html#PLPERL-CONFIG> >>> >> >> The lack of support for SPI functions makes this hardly an adequate solution. I do have both modules and SPI calls inseveral 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_initwith "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 documentationas a place to put .pm files ? -- Alexey Klyukin http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc