On Tue, Jan 12, 2010 at 07:06:59PM -0500, Robert Haas wrote:
> On Sun, Jan 10, 2010 at 4:35 PM, Robert Haas 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 unco
On Sun, Jan 10, 2010 at 4:35 PM, Robert Haas 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 suggested
Tim Bunce 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 nearly robust enough
Andrew Dunstan 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 that. And
> wh
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 w
Tom Lane wrote:
Andrew Dunstan 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_in
Andrew Dunstan 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 PGC_POSTMASTER and the ot
On Sun, Jan 10, 2010 at 2:58 PM, Andrew Dunstan 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 MyApp::Pg;'
>
> I think
Tom Lane wrote:
Robert Haas writes:
On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane 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
etc?
On Sun, Jan 10, 2010 at 2:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane 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
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 m
Robert Haas writes:
> On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane 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
>> etc?
> Same thing that happens wh
On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane wrote:
> Tim Bunce 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 ad
Tim Bunce 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 the record,
I
Andrew Dunstan 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 like rather
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.
On Fri, Jan 08, 2010 at 10:36:43PM -0500, Robert Haas wrote:
> On Fri, Jan 8, 2010 at 10: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 t
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 8, 2010 at 10: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
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 draf
20 matches
Mail list logo
