On Sat, Dec 05, 2009 at 01:21:22AM -0500, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Tom, what's your objection to Shlib load time being user-visible?
It's not really designed to be user-visible. Let me give you just
two examples:
* We call a plperl function for the
Tim Bunce tim.bu...@pobox.com writes:
I'll modify the patch to disable the SPI functions during
initialization (both on_perl_init and on_(un)trusted_init).
Yeah, in the shower this morning I was thinking that not loading
SPI till after the on_init code runs would alleviate the concerns
about
Tim Bunce wrote:
That doesn't even begin to cover the problems with allowing any of
this to happen inside the postmaster. Recall that the postmaster
does not have any database access. Furthermore, it is a very long
established reliability principle around here that the postmaster
process
Andrew Dunstan and...@dunslane.net writes:
If we turn Tim's proposal down, I suspect someone will create a fork of
plperl that allows it anyway - it's not like it needs anything changed
elsewhere in the backend - it would be a drop-in replacement, pretty much.
The question is not about
On Sat, Dec 05, 2009 at 11:41:36AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
I'll modify the patch to disable the SPI functions during
initialization (both on_perl_init and on_(un)trusted_init).
Yeah, in the shower this morning I was thinking that not loading
SPI till
Tom Lane escribió:
David E. Wheeler da...@kineticode.com writes:
Tom, what's your objection to Shlib load time being user-visible?
It's not really designed to be user-visible. Let me give you just
two examples:
* We call a plperl function for the first time in a session, causing
On Thu, Dec 03, 2009 at 04:53:47PM -0800, David E. Wheeler wrote:
On Dec 3, 2009, at 3:30 PM, Tim Bunce wrote:
- New GUC plperl.on_perl_init='...perl...' for admin use.
- New GUC plperl.on_trusted_init='...perl...' for plperl user use.
- New GUC plperl.on_untrusted_init='...perl...' for
On Dec 4, 2009, at 6:18 AM, Tim Bunce wrote:
- generalize the Safe setup code to enable more control.
Is there any possible way to enable use strict; for plperl (trusted)
modules?
I would love to have that feature. Sure does help cut down on bugs and
makes things nicer.
--
Jeff
Jeff thres...@threshar.is-a-geek.com writes:
Is there any possible way to enable use strict; for plperl (trusted)
modules?
The plperl manual shows a way to do it using some weird syntax or
other. It'd sure be nice to be able to use the regular syntax though.
regards,
On Dec 4, 2009, at 3:18 AM, Tim Bunce wrote:
The perl code in plperl.on_perl_init gets eval'd as soon as an
interpreter is created. That could be at server startup if
shared_preload_libraries is used. plperl.on_perl_init can only be set by
an admin (PGC_SUSET).
Are multiline GUCs allowed in
David E. Wheeler da...@kineticode.com writes:
On Dec 4, 2009, at 3:18 AM, Tim Bunce wrote:
The perl code in plperl.on_perl_init gets eval'd as soon as an
interpreter is created. That could be at server startup if
shared_preload_libraries is used. plperl.on_perl_init can only be set by
an
On Dec 4, 2009, at 10:36 AM, Tom Lane wrote:
Are multiline GUCs allowed in the postgresql.conf file?
I don't think so. In any case this seems like an extreme abuse of the
concept of a GUC, as well as being a solution in search of a problem,
as well as being something that should absolutely
Tom Lane wrote:
Jeff thres...@threshar.is-a-geek.com writes:
Is there any possible way to enable use strict; for plperl (trusted)
modules?
The plperl manual shows a way to do it using some weird syntax or
other. It'd sure be nice to be able to use the regular syntax though.
David E. Wheeler da...@kineticode.com writes:
On Dec 4, 2009, at 10:36 AM, Tom Lane wrote:
I vote a big no on this.
That's fine. It's relatively simple for an admin to create a Perl module that
does everything she wants, call it PGInit or something, and then just make
the GUC:
On Dec 4, 2009, at 1:44 PM, Andrew Dunstan wrote:
As is documented, all you have to do is have:
custom_variable_classes = 'plperl'
plperl.use_strict = 'true'
in your config. You only need to put the documented BEGIN block in
your function body if you want to do use strict mode on a
On Fri, Dec 4, 2009 at 1:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On Dec 4, 2009, at 10:36 AM, Tom Lane wrote:
I vote a big no on this.
That's fine. It's relatively simple for an admin to create a Perl module
that does everything she wants,
Robert Haas robertmh...@gmail.com writes:
So, do we look for another way to provide the functionality besides
having a GUC, or is the functionality itself bad?
I don't think we want random Perl code running inside the postmaster,
no matter what the API to cause it is. I might hold my nose for
On Dec 4, 2009, at 10:51 AM, Tom Lane wrote:
plperl.on_perl_init = 'use PGInit;'
No, you missed the point: I'm objecting to having any such thing as
plperl.on_perl_init, full stop.
Aside from the points I already made, it's not even well defined.
What is to happen if the admin changes
On Dec 4, 2009, at 11:05 AM, Tom Lane wrote:
So, do we look for another way to provide the functionality besides
having a GUC, or is the functionality itself bad?
I don't think we want random Perl code running inside the postmaster,
no matter what the API to cause it is. I might hold my
On Fri, Dec 4, 2009 at 2:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So, do we look for another way to provide the functionality besides
having a GUC, or is the functionality itself bad?
I don't think we want random Perl code running inside the
On Fri, Dec 04, 2009 at 11:01:42AM -0500, Tom Lane wrote:
Jeff thres...@threshar.is-a-geek.com writes:
Is there any possible way to enable use strict; for plperl (trusted)
modules?
The plperl manual shows a way to do it using some weird syntax or
other. It'd sure be nice to be able to
David E. Wheeler escribió:
If it's a badly designed concept, do you have any ideas that are less bad?
I'm not sure that we want to duplicate this idea today, but in pltcl
there's a pltcl_modules table that is scanned on interpreter init and
loads user-defined code.
--
Alvaro Herrera
On Fri, Dec 04, 2009 at 02:05:28PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
So, do we look for another way to provide the functionality besides
having a GUC, or is the functionality itself bad?
I don't think we want random Perl code running inside the postmaster,
Le 4 déc. 2009 à 20:40, Tim Bunce a écrit :
Robert's comparison with mod_perl is very apt. Preloading code gives
dramatic performance gains in production situations where there's a
significant codebase and connections are frequent.
How far do you go with using a connection pooler such as
On Dec 4, 2009, at 11:40 AM, Tim Bunce wrote:
Robert's comparison with mod_perl is very apt. Preloading code gives
dramatic performance gains in production situations where there's a
significant codebase and connections are frequent.
The docs for plperl.on_perl_init could include a section
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
So, do we look for another way to provide the functionality besides
having a GUC, or is the functionality itself bad?
I don't think we want random Perl code running inside the postmaster,
no matter what the API to cause it
David E. Wheeler da...@kineticode.com writes:
Tom, what's your objection to Shlib load time being user-visible?
It's not really designed to be user-visible. Let me give you just
two examples:
* We call a plperl function for the first time in a session, causing
plperl.so to be loaded. Later
On Dec 3, 2009, at 3:30 PM, Tim Bunce wrote:
- New GUC plperl.on_perl_init='...perl...' for admin use.
- New GUC plperl.on_trusted_init='...perl...' for plperl user use.
- New GUC plperl.on_untrusted_init='...perl...' for plperlu user use.
Since there is no documentation yet, how do these
28 matches
Mail list logo
