Lists: | pgsql-hackers |
---|
From: | Alexey Klyukin <alexk(at)commandprompt(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | a common place for pl/perlu modules |
Date: | 2010-02-11 16:10:30 |
Message-ID: | FDD4AD42-84B1-43D8-AE79-115E7F2D0F9E@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Alexey Klyukin <alexk(at)commandprompt(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: a common place for pl/perlu modules |
Date: | 2010-02-11 16:24:05 |
Message-ID: | 4B742F25.7050704@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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:
<http://developer.postgresql.org/pgdocs/postgres/plperl-under-the-hood.html#PLPERL-CONFIG>
cheers
andrew
From: | Alexey Klyukin <alexk(at)commandprompt(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: a common place for pl/perlu modules |
Date: | 2010-02-11 16:41:14 |
Message-ID: | 849E83B0-321F-4025-A37C-F73E33E7533B@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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: <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 several pl/perlu functions.
--
Alexey Klyukin http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Alexey Klyukin <alexk(at)commandprompt(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: a common place for pl/perlu modules |
Date: | 2010-02-11 17:07:46 |
Message-ID: | 4B743962.5080203@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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: <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 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
From: | Alexey Klyukin <alexk(at)commandprompt(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: a common place for pl/perlu modules |
Date: | 2010-02-11 17:36:00 |
Message-ID: | 52834ABA-09DF-49F9-BC96-9C8E0F5FF934@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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: <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 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