On Tue, Jan 12, 2010 at 07:06:59PM -0500, Robert Haas wrote:
On Sun, Jan 10, 2010 at 4:35 PM, Robert Haas robertmh...@gmail.com wrote:
I would strongly suggest to Tim that he rip the portions of this patch
that are related to this feature out and submit them separately so
that we can commit
On Sun, Jan 10, 2010 at 4:35 PM, Robert Haas robertmh...@gmail.com wrote:
I would strongly suggest to Tim that he rip the portions of this patch
that are related to this feature out and submit them separately so
that we can commit the uncontroversial portions first.
See my previous email. I
Tim Bunce tim.bu...@pobox.com writes:
On Fri, Jan 08, 2010 at 10:36:43PM -0500, Robert Haas wrote:
I kind of thought Tom said these were a bad idea, and I think I kind
of agree.
Tom had some concerns which I believe I've addressed.
You haven't addressed them, you've simply ignored them. For
On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com writes:
On Fri, Jan 08, 2010 at 10:36:43PM -0500, Robert Haas wrote:
I kind of thought Tom said these were a bad idea, and I think I kind
of agree.
Tom had some concerns which I believe I've
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What happens when the supplied code
has errors, takes an unreasonable amount of time to run, does something
unsafe, depends on the backend not being in an error state already, etc
Robert Haas wrote:
Anyway, I think you've put this pretty well here: the current
definition will make people WANT to use multi-line values for this,
and we don't support that. I think Tim's example is fairly contrived
- setting a global variable here does not seem likely to be useful to
very
On Sun, Jan 10, 2010 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What happens when the supplied code
has errors, takes an unreasonable amount of time to run, does something
unsafe,
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What happens when the supplied code
has errors, takes an unreasonable amount of time to run, does something
unsafe, depends on the backend not being in an
On Sun, Jan 10, 2010 at 2:58 PM, Andrew Dunstan and...@dunslane.net wrote:
I don't know why you would do either of these things. I at least would load
one module which would in turn load others. So I'd expect to see something
like this:
plperl.on_perl_init = 'use lib /my/app; use
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
As an example, if people were using such functionality then the DBA
couldn't start preloading plperl for performance without breaking
behavior that some of his users might be depending on.
If we made plperl.on_perl_init
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
As an example, if people were using such functionality then the DBA
couldn't start preloading plperl for performance without breaking
behavior that some of his users might be depending on.
If we
On Jan 10, 2010, at 11:17 AM, Robert Haas wrote:
It's nicer to write:
plperl.on_perl_init='strict,warnings,LDAP,HTML::Parser,Archive::Zip'
rather than:
plperl.on_perl_init='use strict;use warnings;use LDAP;use
HTML::Parser;use Archive::Zip;'
Well, no, because sometimes I just want to
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
No, they have to all be PGC_POSTMASTER to answer that concern. Only
breaking things for superusers isn't really that big an improvement
over breaking them for everybody.
Well, I don't know about Tim but I think I could live with
Tim Bunce tim.bu...@pobox.com writes:
I didn't get any significant feedback from the earlier draft so here's
the finished 'feature patch 1' for plperl. (This builds on my earlier
plperl refactoring patch, and the follow-on ppport.h patch.)
Just looking over this patch, I don't think it's
On fre, 2010-01-08 at 15:01 +, Tim Bunce wrote:
I didn't get any significant feedback from the earlier draft so here's
the finished 'feature patch 1' for plperl.
I think it would help if you could split this up into about 6 to 10
single-feature patches.
--
Sent via pgsql-hackers mailing
On Fri, Jan 08, 2010 at 10:36:43PM -0500, Robert Haas wrote:
On Fri, Jan 8, 2010 at 10:01 AM, Tim Bunce tim.bu...@pobox.com wrote:
I didn't get any significant feedback from the earlier draft so here's
the finished 'feature patch 1' for plperl. (This builds on my earlier
plperl refactoring
Peter Eisentraut wrote:
On fre, 2010-01-08 at 15:01 +, Tim Bunce wrote:
I didn't get any significant feedback from the earlier draft so here's
the finished 'feature patch 1' for plperl.
I think it would help if you could split this up into about 6 to 10
single-feature patches.
Andrew Dunstan and...@dunslane.net writes:
Peter Eisentraut wrote:
I think it would help if you could split this up into about 6 to 10
single-feature patches.
... having to handle 6 to 10 patches all hitting the same body of code
doesn't sound terrible pleasant either.
Indeed. That sounds
On Jan 8, 2010, at 7:01 AM, Tim Bunce wrote:
I didn't get any significant feedback from the earlier draft so here's
the finished 'feature patch 1' for plperl. (This builds on my earlier
plperl refactoring patch, and the follow-on ppport.h patch.)
Significant changes from the first draft:
On Fri, Jan 8, 2010 at 10:01 AM, Tim Bunce tim.bu...@pobox.com wrote:
I didn't get any significant feedback from the earlier draft so here's
the finished 'feature patch 1' for plperl. (This builds on my earlier
plperl refactoring patch, and the follow-on ppport.h patch.)
Significant changes
20 matches
Mail list logo
